2026年版 PowerBuilder アプリケーション セキュリティ ガイド

セキュリティ強化のためのツールと手法
および現代の基準への準拠

PowerBuilderアプリケーションを扱う開発チーム、セキュリティ担当者、コンプライアンス管理者のための包括的なガイド。

1. はじめに

本ガイドの対象者

PowerBuilderアプリケーションを担当するチーム：開発者、アーキテクト、プロジェクトマネージャー、運用マネージャー。アプリケーションのセキュリティ強化とライフサイクル（開発/テスト/本番環境）の保護方法を説明します。

セキュリティおよびコンプライアンスチーム：アプリケーションセキュリティマネージャー、CISO、GRCチーム、内部または外部監査人。PowerBuilderアプリケーションのセキュリティレベルを評価し、監査やコンプライアンスレビューに備えるのに役立ちます。

本ガイドの目的

PowerBuilderアプリケーションは、重要なプロセス（財務、医療、物流、産業、公共部門）の中核を担っています。設計時よりも高いセキュリティおよびコンプライアンス要件（クライアントワークステーションの保護、強固な認証、暗号化、アクセス制御、トレーサビリティ、監査レポートなど）を満たす必要があります。

こうした状況において、組織は次の3つの目標を同時に達成する必要があります：

  1. アプリケーションを書き換えることなく、PowerBuilderの最新バージョンと専用ツールを活用してセキュリティを強化する。
  2. 主要なリスクを特定し、優先順位を付けて修正し、脆弱性の露出を減らして監査にパスさせます。
  3. 検証可能なエビデンスを提供することで、内部または外部の基準・要件（ISO、NIST、PCI、HIPAA、SOX、GDPR）への準拠を実証する。
PowerBuilderセキュリティにおける3つの目標

得られるもの

本ガイドを読むことで、以下のものを得られます：

  • 実行ファイルの整合性からアクセス制御、監査に至るまで、PowerBuilderアプリケーションのセキュリティ強化に向けた行動計画。
  • これらの技術的措置を規格や規制の要求事項と結びつけるコンプライアンスロードマップ。

本ガイドはモジュール式で、選択的に読むことができます。

各章は独立しており、コンテキスト、脅威、技術的目標、各ツールの機能、主要標準への準拠、証拠など、読みやすい構成になっています。

セキュリティまたはコンプライアンスプロジェクトの基盤として活用できます。

2. 実行ファイルと配布済みコンポーネントの保護

背景とリスク： PowerBuilder アプリケーションは、多くの場合、内部配布メカニズム（ネットワーク共有、パッケージ、汎用配布ツール）を介して配布され、配信された実行ファイルに対する暗黙の信頼に基づいています。

ワークステーションの強化に伴い、署名されていない、または追跡不可能な実行ファイルはしばしばブロックされますが、制御が脆弱な場合、侵害されたバイナリが受け入れられる可能性があります。

このリスクは、導入の容易さを超えたものです。2023 年の 3CX インシデントで明らかになったように、ソフトウェアチェーンが侵害されるシナリオに相当します。このインシデントでは、正規のアプリケーションが感染し、大規模に配布され、検出されるまでに複数の侵入の道が開かれてしまいました。

さらに、攻撃者は署名付き要素への信頼を悪用しようとします。Sophos （世界的なサイバーソリュー ション セキュリティ ベ ンダー）は、133 の悪意のある Windows ドライバを文書化しており、そのうち 100 は WHCP プログラムを通じて署名されていました。

解決策は、検証可能な信頼の連鎖を確立することです。公開前に分析し、成果物に体系的に署名し、配布されたバージョンを追跡し、公開権限を制限します。
信頼の連鎖：ソースコードから安全なデプロイまで

目的

  • アプリケーションのバージョンに関連付けられた、再現可能でバージョン管理されたコンパイルプロセスを実装する。
  • 組織が承認した証明書で、実行ファイル、ライブラリ、および配布パッケージに体系的に署名する。
  • 配布前に成果物の整合性を検証する（例：ハッシュによる）。
  • 配布されたバージョン、そのハッシュ、リリース日、責任者を追跡する。
  • 配布とセキュリティに関連する公開権限および管理権限を制限し監査する。

機能とツール

PowerServer および PowerClient プロジェクトを含め、コード署名をコンパイルおよび配布プロセスに統合する。 PB
拡張検証証明書（EV 証明書）を使用してアプリケーションに署名し、ユーザーの信頼性と最新のセキュリティポリシーとの互換性を向上させます。 PB
PowerBuilder 専用セキュリティルール（SAST）による PowerBuilder コードの分析と、脆弱性および不適切な手法の検出により、安全なデリバリーを実現します。 VE
コード内のハードコードされた識別子/パスワード、暗号化キー、およびIP アドレスを検出し、デコンパイルやデプロイメントスクリプトのコピーによる漏洩リスクを低減します。 VE

コンプライアンス

この章では、ISO 27001 や SOX 準拠の環境でよく見られる、ソフトウェアの完全性およびリリースサイクル管理に関する期待事項について取り上げます。 (セキュリティ基準とコンプライアンス)

証拠

  • 署名手順（証明書、タイムスタンプ、責任範囲）およびパイプライン内での実行証明。
  • 署名済みバージョンに関連する Visual Expert レポート（脆弱性、深刻度、修正内容）。
  • 機密操作（管理、権限変更）に関するVisual Guard監査履歴 (監査履歴)。

3. 保存時および転送中のデータの暗号化

背景とリスク： PowerBuilderアプリケーションは、機密データ（業務、個人情報、医療、金融など）を頻繁に処理します。このデータはクライアント、データベース、中間コンポーネント間で転送されます。また、エクスポート、一時ファイル、アプリケーションログ、バックアップにも存在します。

システムおよびデータの可用性喪失は一般的な問題であり、ランサムウェアは確認済み侵害事例の44%に存在します（Verizon 2025 DBIR – エグゼクティブサマリー）。

しかし、こうした攻撃は、事前の情報流出（「二重の恐喝」）を伴う場合があり、インシデントをデータ漏洩やコンプライアンスの危機へと発展させる可能性があります（CISA – ランサムウェアガイド）。

医療分野では、MD アンダーソン事件が、暗号化されていないストレージ（ワークステーション、ノートパソコン、リムーバブルメディア）のために、規制当局による大きな制裁措置につながりました。

解決策は、保存時の暗号化、転送中の暗号化、厳密なキー管理、関連する権限の制限などにより、そのコンテキスト外ではデータを読み取れないようにすることです。
保存時および転送中データの暗号化

目的

  • アプリケーションが扱う機密データとその保存場所（データベース、ファイル、エクスポート、ログ、バックアップ）を特定する。
  • 秘密情報や機密性の高いパラメータを暗号化し、コード、スクリプト、設定ファイルに平文で表示されないようにする。
  • クライアントワークステーション、アプリケーションサーバー、データベース間の通信を、会社が推奨する暗号化モードを適用して暗号化する。
  • クライアントワークステーションに重要なデータが含まれる可能性がある場合、ローカルストレージと機密エクスポートを保護する。
  • 使用されているアルゴリズム、鍵サイズ、暗号化パラメータが準拠し維持されていることを確認する。

機能とツール

トランザクションオブジェクトの接続プロパティを暗号化し、Secure Connection Encryptor を使用して暗号化された接続文字列を生成し、スクリプトやファイルに平文の認証情報が含まれないようにします。 PB
SQL Server ドライバーおよびデータベース側で TLS/‘Strict’ 暗号化を有効にすることで SQL Server 接続を暗号化し、証明書を検証します。 PB
CoderObject および CrypterObject オブジェクトを使用してデータをエンコードおよび暗号化します。 PB
PowerBuilder コードをスキャンして、DES/3DES、廃止されたハッシュ関数 (SHA-1/MD5 など)、暗号化モード、ハードコードされたキー、または 堅牢ではないキーサイズ の使用を検出します。 VE
権限/ロールモデル を介して機密データや機能へのアクセスを厳密に制御し、リスクを軽減します。 VG
機密データおよび重要操作へのアクセスを記録し、詳細な監査（誰が、何を、いつ、どこから行ったか）を可能にします。トレーサビリティと監査 VG

コンプライアンス

本章は、ISO 27001、NIST SP 800-53、PCI DSS、および状況に応じて HIPAA や GDPR における機密性およびデータ保護の要件に貢献します。 (セキュリティ基準とコンプライアンス)

エビデンス

4. 現代的で安全なネットワークプロトコルの採用

背景とリスク： PowerBuilder アプリケーションのインフラストラクチャは、長年にわたって進化してきました（ドライバ、ミドルウェア、プロキシ、ゲートウェイ）。

古いプロトコルの使用、脆弱な暗号スイート、または暗号化されていないチャネルの使用により、トラフィック（認証、データ、トークン）の傍受や改ざん、あるいはプロキシ、サーバー、データベースがTLS 1.2以上または厳格モードを要求する場合のアプリケーションのブロックといったリスクが生じます。これによりセキュリティインシデントが本番環境の問題に発展します。

NIST SP 800-52r2 公開文書では、最低限 TLS 1.2 を推奨し、ダウングレード攻撃や暗号化エラーを減らすための設定要件を定めています。

コンプライアンスの観点では、PCI DSS は公開ネットワーク経由で送信される決済データを保護するため、強固な暗号技術の使用を義務付けています。

解決策は、トラフィックフローのインベントリ作成、TLS設定の強化、ネットワークコンポーネントの標準化です。
多層防御：ネットワークセキュリティレイヤー

目的

  • アプリケーションが使用するネットワークフローと、実際にネゴシエートされたプロトコル（TLS バージョン、暗号スイート、証明書）をインベントリ化する。
  • 廃止されたプロトコルを排除し、組織のセキュリティポリシーに沿った TLS バージョンと構成を適用する。
  • 環境が要求する場合、特に内部 API やパートナーに対して、相互認証（クライアント証明書）を実装する。
  • バイパスやサイレントな劣化を防ぐため、証明書検証とエラー処理を標準化する。
  • プロキシ、ゲートウェイ、ネットワーク保護との互換性をテストし、セキュリティ制御による本番環境のブロックを防止する。

機能とツール

TLS 1.3 および HTTP/2 を HTTPClient および RESTClient オブジェクトでサポートします。 PB
内部 API やパートナーサービスなどで使用される 相互 TLS 認証（クライアント証明書） をサポートします。 PB
コード通信ポイント（HTTPクライアント、Webサービス呼び出し、証明書管理）を識別します。 VE
最新のセキュリティプロトコルをサポートしていない使用例（例：SOAP/INETサービスへの呼び出し や 非セキュアな認証API の使用）を検出します。ネットワークリファクタリングを優先します。 VE
標準化された Web サービス を専用サーバー経由で使用し、認証、アクセス制御、ログ記録を集中化するとともにクライアント側のセキュリティロジックを制限します。 VG

コンプライアンス

本章は、ISO 27001 および NIST の通信セキュリティに関連する統制に貢献し、金融および医療分野における監査要件を頻繁に満たします。 (セキュリティ基準とコンプライアンス)

エビデンス

5. 外部サービスおよびAPIとの安全な通信

背景とリスク： システムの近代化に伴い、多くのPowerBuilderアプリケーションがAPIを利用したり、SaaSプラットフォームと通信したり、メッセージングや内部サービスを介した交換を自動化しています。

この開放性はプロジェクトを加速させる一方で、侵入経路も生み出します：不完全なアクセス制御、過度に許可的なトークン、不十分な入力検証、環境間で共有されるシークレットなどです。ローカルに保存されたトークンや環境間（開発/テスト/本番）で共有されたトークンを使用してAPIを呼び出すアプリケーションは、ワークステーションの侵害や設定漏洩が発生した場合に攻撃の入り口となる可能性があります。

OWASPは、API側の最も重大な弱点は依然として オブジェクトレベルのアクセス制御の欠如 であると指摘しています。

ビジネスプロセスに関しては、FBI IC3 2024年報告書 によると、ビジネスメールの侵害に関連する損失は27億7000万ドル（電信送金詐欺、請求書ハイジャックなど）と推定されています。

約1,000万人の顧客に影響を与えた Optusインシデント（2022年） は、顧客データがインターネット経由でアクセス可能になった場合の危険性の大きさを示しています。

対応策としては、認証の標準化、権限と露出面の制限、交換の制御が挙げられます。
統合とセキュリティ制御ポイント

目的

  • 統合箇所（API、内部サービス、SMTP）と交換されるデータを特定する。
  • システム間での標準認証（例：OAuth）を実装する。
  • トークンおよび技術アカウントに関連する権限を厳しく制限する。
  • ハードコードされたシークレットを削除し、その保存、ローテーション、失効を整理する。
  • メッセージやログに機密情報を露出させない。
  • 影響の大きい操作（エクスポート、送信、重要なアクション）を管理および追跡する。
  • 不正利用を検知するメカニズムを導入する。

機能とツール

RESTClient を使用した REST ベースの統合を優先する。SOAP が必要な場合は、強力な認証を備えた TLS 1.2 以上の HTTPClient を使用し、レガシー SOAP クライアントの実装は避けてください。 PB
一般的な API 統合の慣行に合わせて、OAuth 2.0 認証プロトコルを使用します。 (強化された RESTClient オブジェクト - 新機能) PB
ユーザー名とパスワードを送信する代わりに、トークンベースの認証（OAuth 2.0 ベアラートークン）を使用し、HTTPClient および OAuthClient でトークンを管理してください。(HTTPClient および OAuthClient の機能強化 - 新機能) PB
SMTP をネイティブでサポートし、最新の認証方法（XOAUTH2 を含む）を使用します。脆弱な可能性のある社内実装を減らします。ネイティブメールサポート（SMTP クライアント） - 新機能 PB
コードをスキャンして、SQL、OSコマンド、パスへのコードインジェクション、ハードコードされたシークレット、不十分なエラー処理、交換データの制御不足による攻撃の可能性を特定します。 VE
機密性の高い呼び出し（エクスポート、送信、ビジネスアクション）をトリガーできるユーザーを制限します。 VG
監査および調査のためにこれらの操作を追跡します。重大または異常なイベントが発生した場合にリアルタイムで監視し、通知をトリガーします。 VG

コンプライアンス

統合管理機能は、ISO 27001、NIST、PCI DSS、および適用範囲に応じてHIPAAのセキュリティとトレーサビリティ要件に貢献します。 (セキュリティ基準とコンプライアンス)

エビデンス

6. 組み込みブラウザに関連する攻撃対象領域の削減

背景とリスク： PowerBuilderアプリケーションに組み込まれたブラウザは、HTMLコンテンツの表示、ポータルの統合、またはWebページ経由の認証を容易にするために使用できます。

これらの統合はレガシーコンポーネントに基づく場合があります。マイクロソフトは2022年6月にIE11のサポートを終了し、現在は EdgeのIEモードの使用 を推奨しています。古いWebコントロールを維持することは、脆弱性のリスクや望ましくないコンテンツが実行されるリスクを生じさせます。

Microsoftのドキュメント では、WebBrowserコントロールが「完全信頼」モードで動作し、外部サーバー由来の潜在的に危険なスクリプトやコンテンツの実行を防止しない点も指摘されています。

MSHTMLエンジンの脆弱性は、CISAアラートを発動させた CVE-2021-40444 など、標的型攻撃ですでに悪用されています。

この状況を踏まえ、アクセスするWebコンテンツを制限し、コンポーネントを隔離し、最新のサポート対象エンジンへ移行することが推奨されます。
組み込みブラウザのセキュリティ強化：制御ポイント

目的

  • ブラウザを使用している画面、期待されるコンテンツ、および許可されたURLをリストアップする。
  • 最新のブラウザへ移行し、サポートされていないコンポーネントを削除する。
  • 特に外部サーバーからのコンテンツについて、ブラウジング、URLのオープン、スクリプト実行を厳格に制限する。
  • アプリケーションとWebページ間の通信（JavaScriptインタラクション）を監視し、望ましくない実行やアクセスを防止する。
  • 本番環境ではリモートデバッグを無効化する。

機能とツール

Microsoft Edge WebView2 に基づく 最新化されたWebBrowser コントロールを使用し、関連する機能強化を適用します。 PB
JavaScript実行やページ操作に関する WebBrowserの改善 を活用します。 PB
診断目的で WebBrowserのリモートデバッグ を有効化できます。この機能は厳重に管理し、本番環境では無効化する必要があります。 PB
OLEブラウザや廃止されたコンポーネント の使用を検出します。これらは脆弱性やセキュリティ上の非互換性にさらされやすいためです。 VE
WebBrowserの使用状況（URLの開く操作、スクリプトの実行、コンテンツの操作）を調査・分析し、リスクのある画面を特定して修正の優先順位を決定します。 VE
Webコンテンツを統合する画面や機能へのアクセスを制限します。 VG
ブラウザに関連する機密性の高い操作を追跡し監査します。 VG
ウェブコンテンツを表示する画面や機能へのアクセスをリアルタイムで監視し、異常な動作が発生した場合にチームに通知します。 VG

コンプライアンス

この章は、ISO 27001 および NIST で一般的に求められる、攻撃対象領域の削減およびアクセス制御に関連する要件をサポートします。 (セキュリティ基準およびコンプライアンス)

エビデンス

7. ビルドおよび配布チェーンのセキュリティ確保

背景とリスク： アプリケーションのセキュリティはソースコードに限定されません。アーティファクトを生成・公開するチェーン（ビルドサーバー、スクリプト、依存関係、サービスアカウント、署名キー、リポジトリ、本番プロセス）にも依存します。

1つのリンクが侵害されると、攻撃者は更新プログラムに悪意のあるコードを注入し、すべてのユーザーに影響を与える可能性があります（共有ビルドサーバー、配布サービスアカウント、証明書／署名キーの保存場所など）。

SolarWindsインシデント は、広く導入されたソフトウェアプログラムの製造および配布チェーンが侵害されたことで、このシナリオが大規模に発生する可能性を示しました。

より一般的には、2025年DBIR では、分析対象の侵害事例の30%にサードパーティが関与していたことが示されており、前年の約15%から増加していることから、依存関係と共有アクセスの管理の重要性が強調されています。

推奨される対応策は、DevOpsプロセスに沿った完全性管理（署名、ハッシュ、SBOM）、技術アカウント権限の削減、シークレットガバナンス（ローテーション、漏洩検知、失効）を組み合わせたものです。
ビルドおよびデプロイメントチェーンの保護 - DevSecOps サイクル

目的

  • ビルド、テスト、セキュリティ分析、署名、配布を統合した標準パイプラインを定義し、明確な合格基準を設定します。
  • ツールのバージョン、依存関係、コンパイルパラメータを管理することで、ビルドを再現可能にします。
  • パイプラインで使用されるサービスアカウント、シークレット、署名キーを保護し、その権限を制限します。
  • 監査証拠を提供し、調査を容易にするため、各バージョンに関連する成果物とレポートを保持します。

機能とツール

ソリューション形式 に切り替えてコードをテキストに変換し、バージョン管理ツールや自動化ツールとの統合を容易にします。 PB
PBAutoBuild を使用してビルドスクリプトを簡素化し、パイプラインを標準化します。 PB
PB 2025で マージ競合を減らし 、レビューとトレーサビリティを容易にします。 PB
トリガー、ビルド受け入れ基準、ダッシュボードなど、すべてのビルドで静的脆弱性分析（SAST）を工業化します。 VE
例外が無視されず、本番環境でコンソールログが使用されていないことを検証します。 VE
環境間（開発/テスト/本番）におけるアクセス制御設定（権限、ロールなど）のデプロイを自動化し、不一致やエラーを削減します。 VG

コンプライアンス

この章は、ISO 27001 および、該当する場合は内部統制要件（SOX）に関連するガバナンスとトレーサビリティの要件に貢献します。 (セキュリティ基準とコンプライアンス)

エビデンス

8. 認証とアクセス制御の強化

背景とリスク： 多くのPowerBuilderアプリケーションでは、ユーザー認証にアプリケーションデータベースに保存されたログイン／パスワードアカウントを依然として使用しています。

  • パスワード認証は限定的なセキュリティしか提供せず（脆弱なパスワード、共有アカウント）、リスクをもたらします。なぜなら、アイデンティティが主要な攻撃ベクトルとなっているからです：2025年DBIRで調査された侵害事例の22%は、侵害された認証情報の使用から始まりました。
  • このアプローチでは、各アプリケーション固有のユーザーアカウント（サイロ化されたアカウント）を管理する必要が生じ、管理コストが増加します。
  • また、管理者が管理・監視すべきアカウントが増えるため（非アクティブアカウント、過剰な権限、職務分離の欠如など）、異常発生のリスクも高まります。

適切な戦略は、Active DirectoryやEntra IDなどの単一のIDストアにユーザーアカウントを集中管理し、機密性の高いアプリケーションには多要素認証（MFA）による追加の保護層を追加することです。
認証とアクセス制御：アーキテクチャとフロー

目的

  • ユーザーIDを一元管理します。ローカルアプリケーションアカウントの使用を削減します。例えば、Active DirectoryまたはMS EntraIDに保存されているWindowsアカウントに置き換えます。
  • 機密性の高いアプリケーションや特権アカウントには強力な認証（MFA）を導入します。
  • 最小権限の原則を適用し、一貫した役割と権限を通じて権限をモデル化します。
  • 重要な操作に対する職務分離を実施し、承認の競合を処理します。
  • 権限の定期的な見直しを実施し、機密性の高いログインや操作の監査証跡を維持します。

機能とツール

アプリケーションがIDサービスと連携する際、PBネットワークオブジェクト HTTPClient／OAuth／RESTClient を使用して、最新の認証およびトークンメカニズムを統合します。 PB
コード内の認証/認可の実装を識別し、一般的な脆弱性（回避可能な制御、ハードコードされた権限、ロギングの欠如）を検出します。 VE
強力な認証（MFA）を実装し、ケースに応じて、Windows 認証、ログイン/パスワード、または同じアプリ内での混合モードを選択します。 VG
複数のディレクトリに分散したIDを管理（フェデレーション）し、組織構造を反映した階層的なグループにユーザーを編成することで、権限付与の委任と工業化を実現します。 VG
職務分離（SoD）を通じて権限衝突を特定し修正します。 VG
権限マトリックスを生成し、監査対応可能なレポートを作成します。 VG

コンプライアンス

この章では、ISO 27001、NIST SP 800-53、および PCI DSS のIAMおよびアクセスガバナンス要件に直接対応し、特に金融、医療、上場企業セクターに関連しています。（セキュリティ基準とコンプライアンス）

エビデンス

  • 役割／グループ／ユーザー別の権限マトリックスおよび定期的な見直しの証拠。（権限マトリックス）
  • 文書化された職務分離（SoD）ルール、検出された衝突の一覧、および是正計画。（職務分離（SoD））
  • 機密性の高い接続および操作の監査ログ（保持期間およびエクスポート機能付き）。（監査活動）

9. オプション：PowerServerによるモダンアーキテクチャへの移行

背景とリスク：

一部のPowerBuilderアプリケーションは現在、リモートアクセス（VPN、アプリケーションゲートウェイ、仮想化）が可能ですが、データベースに直接接続し、クライアントワークステーションに保存されたパラメータに依存する「厚いクライアント」も維持されています。

このモデルでは、ネットワーク境界やリモートアクセスポイントに配置された機器が重要な侵入経路となるため、一定のリスクが生じます。また、ワークステーションごとに秘密情報や接続パラメータを管理することがより困難になります。

DBIR 2025によると、脆弱性の悪用は初期アクセスのおよそ20%を占めています。特にリモートアクセス機器に影響を与える脆弱性は、30日以内に修正される割合が54%に留まることから、極めて敏感な問題であることが強調されています。

解決策は、ワークステーションへの依存度と露出を低減するため、多階層アーキテクチャへの移行です。アプリケーションサーバーが.NET API（PowerServer）を公開し、適切な位置（認証、ログ、ネットワークセグメンテーション）に集中管理されたID管理と制御機能を配置します。

目的

  • クライアントワークステーションからのデータベースへの直接アクセスを減らすため、APIを公開するサーバー層でアクセスを一元化します。
  • サーバーサイドのセキュリティ制御（認証、認可、ログ記録）を集中化し、クライアントアプリケーションやローカル設定への依存を制限します。
  • API認証とトークン管理を標準化し、組織の慣行に整合させます。
  • 最も機密性の高いモジュールを優先し、段階的な進化を計画します。

機能とツール

PowerServerを使用して、サーバー側の n 層アーキテクチャに移行し、クライアント ワークステーションからの直接データベース アクセスを削減します。 PB
Web APIに OAuth 2.0 や JWT などの認証メカニズムを実装し、不正アクセスを防止します。 PB
サーバーコンポーネントを.Netのサポート対象バージョンに更新します。 PB
アーキテクチャ変更の前、最中、後に、アプリケーションのマッピング、依存関係の特定、既存コードのセキュリティ確保を行います。 VE
標準ツールを使用して、ユーザー、API アクセス権限を管理し、監査レポートを生成します。 VG
複数のアプリケーションのセキュリティを一元化し、IDと権限の包括的な可視化を実現するとともに、制御、ログ記録、監査を標準化します。 VG

コンプライアンス

この章は、ISO 27001およびNISTで頻繁に強調される、監査可能で標準化されたアーキテクチャへ整合させるアプローチの一部です。（セキュリティ基準とコンプライアンス）

エビデンス

10. アプリケーションを現代の標準に準拠させる

背景とリスク：

規制対象分野（金融、医療、上場企業）では、セキュリティ強化だけが目的ではありません。

これらの組織は、アプリケーションが現代の基準に準拠していることを実証しなければなりません。また、機密機能にアクセスできるのは誰か、どのような権限が付与されているか、どのようなアクションが実行されているか、そして重要なデータをどのような対策で保護しているかなど、具体的な検証可能なチェックを実施する必要があります。

この要件は、透明性に関する義務によってさらに強化されています。例えば米国では、SEC は上場企業に対して、厳格に規制された手順に従って特定の「重要な」サイバーセキュリティインシデントを報告するよう義務付けています。

さらに、データ侵害による世界平均の損失額は2024年に488万ドルに達し、コンプライアンスのギャップが直接的な財務リスクへと変化しています。

こうした状況において、組織は今や統制を体系化し、証拠（レポート、ログ、アクセスレビュー、変更のトレーサビリティ）を提示しなければなりません。

重複を避け、監査準備を容易にするため、この章では上記の機能をコンプライアンス要件と関連付けて説明します。

目的

  • 適用される基準と、アプリケーションのコンプライアンスで期待される範囲（内部および外部の要件）を定義します。
  • これらの要件を測定可能な統制に翻訳し、さらに監査のための証拠へと変換します。
  • 証拠（レポート、ログ、アクセスレビューなど）のリポジトリを確立します。
  • ガバナンス（アクセスレビュー、例外管理、職務分離（SoD）の競合処理）を正式化し、標準化された監査ファイルを準備します。

機能とツール

コード署名、DB/ドライバー接続の暗号化、セキュアなネットワークプロトコル、OAuth/REST統合機能など、頻繁に求められる要件をサポートします。 PB
脆弱性の低減および継続的改善アプローチの実証に役立つ、繰り返し可能でバージョン管理された分析（特にPowerBuilderセキュリティルールに関する分析）を提供します。 VE
セキュリティチェックおよびレポートを自動化し、IAM、RBAC、職務分離、追跡可能性、監査といった現代的な基準に準拠します。 VG
権限マトリックスを公開することで、「誰が何にアクセスできるか」を文書化します。 VG
ソースコードの脆弱性検出において再現性のある結果を生成するため、検査ルールのリポジトリを活用します。 VE

コンプライアンス

Visual Guard は、サポートされている標準（ISO 27001、NIST SP 800-53、NIST SP 800-63、CIS Controls、PCI DSS、GDPRなど）のマップを公開し、関連するメカニズム（MFA、RBAC、SoD、ロギング、アクセスレビュー）を示しています。（セキュリティ基準とコンプライアンス）

エビデンス

PowerBuilderアプリケーションのセキュリティ確保のためのチェックリスト

これらのチェックリストは、ほとんどのコンテキストに適用可能なアクションの後に、組織のアーキテクチャと規制上の制約に応じてアクティブ化されるオプションのアクションが続くという実用的なアプローチを提供します。

チェックリスト A - 汎用対策（ほとんどのケースで推奨）

章対策

横断的（前提条件）

 アプリケーション、環境、依存関係、フロー（ワークステーション、サーバー、データベースなど）をインベントリ化する。
取り扱うデータを分類し、関連する保護要件を正式に定義する。
修復プロセスを確立する（優先順位付け、目標タイムライン、検証、追跡）。
パッチ適用と公開コンポーネントの更新（OS、データベース、ミドルウェア、ライブラリ、リモートアクセス）。
インシデント対応計画を正式化し、DR/BCP（復旧、回復）をテストする。

2. 実行ファイルとコンポーネント

 特定可能なリリースに紐づく、再現可能なバージョン管理されたビルドプロセスを作成する。
会社承認の証明書を使用して、すべての実行ファイル、ライブラリ、配布パッケージに署名する。
配布前にアーティファクトの完全性を検証（ハッシュ/フィンガープリント）し、結果を記録する。
配布されたバージョン（ハッシュ、日付、所有者）を追跡し、履歴を保持する。
配布に関連する公開権限と管理権限を制限し監査する。
リリース前にPowerBuilderコードをスキャンし、脆弱性と不適切な慣行を特定する。
コードやスクリプトからハードコードされた機密情報（ID、パスワード、キー、IPアドレス）を検出し削除する。

3. データの保護

 機密データとその保存場所（データベース、ファイル、エクスポート、ログ、バックアップ）を特定する。
DBサーバーおよびPB DBドライバーでTLS 1.2以上（証明書検証を含む）を使用するようにTLSを有効にする。
必要に応じて保存中の機密データを暗号化する（データベース、ファイル、エクスポート、バックアップ）。
暗号化キーを保護する（保管、アクセス制御、ローテーション、失効）。
接続プロパティを暗号化する。暗号化された接続文字列を生成する（平文のシークレットは使用しない）。
脆弱な暗号化方式（例：DES/3DES）を検出し排除する。堅牢なモードを強制する。
廃止されたハッシュ（例：SHA-1/MD5）を検出し排除し、堅牢な代替手段を強制する。
セキュリティポリシーに対して暗号の強さ（鍵サイズ、動作モード、パディング）を検証する。
ロール/権限によるアクセスを厳しく制限し、機密データへの露出を減らす。

4. ネットワークプロトコル

 ネットワークフローと実際にネゴシエートされたプロトコル（TLSバージョン、スイート、証明書）をインベントリ化する。
廃止されたプロトコルを削除する。TLS設定を会社のポリシーに合わせる。
証明書検証とエラー処理（バイパスやサイレントダウングレードを許さない）。
必要に応じて相互TLS認証（mTLS）を実装する（内部/パートナーAPI）。
プロキシ、ゲートウェイ、ネットワーク保護機能との互換性をテストする（RESTClient / HTTPClient）。
準拠していない、またはレガシーなネットワーク呼び出しを検出し、その置換を優先する。

5. 外部サービスおよびAPIとのやり取り

 統合（API、内部サービス、SMTP）および交換されるデータをインベントリ化する。
統合にはSOAP/INETよりRESTを優先する（RESTClient）。
SOAPが必要な場合は、TLS 1.2以上と強力な認証を備えたHTTPClientを使用し、レガシーSOAPクライアントは避ける。
HTTPClient/OAuthClientを使用し、ユーザー名とパスワードではなくトークンベース認証を採用する。
トークンおよび技術アカウントの権限を厳格に制限する（スコープ、権限）。
ハードコードされたシークレットを削除し、環境ごとに保管、ローテーション、失効を管理する。
入力とパラメータにおける注入リスク（SQL、OSコマンド、パス）を検知し修正する。
公開フロー（サービス、API、ファイル、メール）における入力の検証と出力のエンコードを実施する。
機密操作（エクスポート、送信、重要アクション）の追跡と監視／アラート設定を実施する。

6. 組み込みブラウザ

 ブラウザを埋め込んだ画面をインベントリ化し、期待されるコンテンツと許可されたURLを定義する。
サポートされている最新のブラウザエンジンに移行し、廃止されたコンポーネントを削除する。
信頼できないコンテンツに対するブラウジング、URLオープン、スクリプト実行を制限する。
望ましくない実行を防ぐため、JavaScriptインタラクション（アプリケーションブリッジ）を管理する。
本番環境でのリモートデバッグを無効化し、管理された診断に限定する。
「Web」画面へのアクセスを制限する。
ウェブアクセスを監視し、異常な動作時に通知をトリガーする（トレーサビリティと監査）。

7. ビルドと配布

 明示的な合格基準を持つ標準パイプライン（ビルド、テスト、分析、署名、デプロイ）を定義する。
バージョン管理と自動化を簡素化するためソリューション形式に移行する（Solution）。
マージ競合を減らしトレーサビリティを向上させるため、PB 2025+ へ移行する。
ビルドの再現性を確保（バージョン、依存関係、パラメータ）。バージョンごとの成果物とレポートを保持する。
パイプラインの技術アカウントを保護（最小権限、役割分離、監査）。
パイプラインのシークレットとキーを保護する（安全な保管、アクセス制限、ローテーション）。
すべてのビルドでSAST分析を工業化し、重大なルール違反が発生した場合はリリースをブロックする。
本番環境での危険な慣行（例：コンソールログ出力）を回避し、例外を無視しない。
開発/テスト/本番環境間でセキュリティ設定のデプロイを標準化する（不一致を回避）。

8. 認証とアクセス制御

 ID管理を集中化（AD/Entra ID）し、ローカルアプリケーションアカウントを削減する。
機密性の高いアプリケーションと特権アカウントには多要素認証（MFA）を有効化する。
最小権限の原則に沿ったロールと権限を通じて権限をモデル化する。
専用サーバー（Identity Server）を介して認証、認可、ログ記録を一元化する。
重要な業務における職務分離（SoD）を実施し、競合を解消する。
定期的なアクセス権限の見直しを実施し、証拠を保持する。
監査対応の権限マトリックスを作成する（誰が何をアクセスできるか）。
機密性の高いログインと操作（誰が、何を、いつ、どこで）をログ記録し、監視を一元化する。

10. 現代的な基準への準拠

 適用される基準とアプリケーションのコンプライアンス範囲を定義する。
要件を測定可能な管理措置と期待される証拠（レポート、ログ、アクセスレビュー）に変換する。
証拠リポジトリを確立し、バージョン/環境ごとに履歴を保持する。
ガバナンスを標準化する（アクセスレビュー、例外管理、SoD（職務分離）の競合処理）。
要件、統制、ツール、証拠を連携させた再利用可能な監査パックを構築する。

 

チェックリスト B - アーキテクチャと環境に応じたオプション対策

章対策

5. 外部サービスおよび API との交換

 アプリケーションがAPIを消費する場合：強力な認証と鍵/トークンのローテーション（OAuth 2.0）
アプリケーションがAPIを消費する場合：トークンのスコープと権限を制限する（OAuthClient）
メールの場合：ネイティブメールサポートと最新認証方式を使用（SMTPクライアント／XOAUTH2）
メールの場合：セキュアな中継（認証、TLS）、添付ファイルの制限、機密送信の追跡（XOAUTH2）

6. 組み込みブラウザ

 Web/HTMLコンポーネントの場合：コンテンツを制御し、信頼できないスクリプトを制限する（WebBrowser）
Web/HTMLコンポーネントの場合：レガシーエンジンをサポート対象エンジンに置き換える（WebView2）

7. ビルドとデプロイ

 工業化の場合：ビルドスクリプトとパイプラインオーケストレーションを標準化（PBAutoBuild）
より強力なQAの場合：分析結果に基づく受け入れ基準を構築（SAST）

8. 認証とアクセス制御

 権限衝突がある場合：職務分離（SoD）ルールと是正措置を定義する
組織が複雑な場合：組織構造を反映したユーザー・グループ階層を構築し、権限を委譲する。
複数のディレクトリにIDが分散している場合：IDフェデレーションを実装する。
組織が監査を実施する場合：権限マトリックスを生成・活用する（Permission Matrix）

9. PowerServerによるモダンアーキテクチャ

 クライアントからデータベースにアクセス可能な場合：PowerServerを用いたn層アーキテクチャへ移行
アプリケーションがAPIを公開/利用する場合：API認証を標準化（OAuth 2.0）
アプリケーションがAPIを公開/利用する場合：標準トークンを使用し、不正アクセスを制限する（JWT）
サーバーサイド制御（認証、認可、ロギング）を集中化する。
最も機密性の高いモジュールを優先して段階的な移行を計画する（プログレッシブ移行）。
サーバーコンポーネントをサポート対象の.NETバージョンに更新する（.NET）。
APIアクセス権限を管理し、監査レポートを生成する（権限／監査活動）。

10. 現代的な標準への準拠

 厳しい要件がある場合（金融、医療など）：コンプライアンスガバナンスと正式な制御（監査活動）
厳格な要件がある場合：監査証拠とその保持の工業化（権限マトリックス）

 

よくある質問

まず全体像を把握することから始めます。コンポーネント（実行ファイル、DLL、OCX、スクリプト）、フロー（ワークステーション ↔ サーバー ↔ データベース）、機密データ、依存関係を洗い出します。次にPowerBuilderコードに対してSASTスキャンを実行し、脆弱性と不適切な手法を迅速に特定し、修正の優先順位付けを行います。 最後に、コード署名、転送中の暗号化、アクセス制御、ログ記録、監査証跡などの「基盤」を整えます。
一般的な発見事項には、ハードコードされた機密情報（ユーザー名、パスワード、キー）、レガシーなネットワーク呼び出し、「ケースバイケース」で実装され監査が困難なアクセス制御、不十分な入力検証（SQL/コマンド/パスインジェクションリスク）、調査を支援するには脆弱すぎるログ記録が含まれます。PowerBuilderに特化したSASTスキャンは、これらのリスクを可視化し、修正対象を特定する効果的な方法です。
ワークステーション、アプリケーションサーバー、データベース間の転送データを暗号化することが目的です。クライアント側とサーバー側の両方でTLS設定（バージョン、暗号スイート、証明書）を確認してください。データベースに応じて利用可能な最も厳格な暗号化モードを有効化し、プロキシ、ゲートウェイ、強化されたネットワークポリシーが存在する環境での互換性をテストしてください。
転送中の暗号化はネットワーク上のデータ（傍受、改ざん）を保護します。保存中の暗号化は、盗難、不正アクセス、侵害が発生した場合に保存されたデータ（データベース、ファイル、エクスポート、ログ、バックアップ）を保護します。両者は補完関係にあります。暗号化された通信経路は、保護されていないローカルエクスポート経由の漏洩を防げません。同様に、暗号化されたストレージは、通信が暗号化されていない場合、ネットワークスニッフィングを防げません。
脆弱または陳腐化したアルゴリズムや関数（例：DES/3DES、MD5、SHA-1）、不適切なモードやパディングは避けるべきです。堅牢なパラメータ（鍵サイズ、動作モード）と適切な鍵管理（保管、ローテーション、失効）を備えた現代的なアルゴリズムを優先してください。「適切なアルゴリズム」＋「適切なパラメータ」＋「適切な使用法」など、一貫性が重要です。
信頼の連鎖を確立する：再現可能かつバージョン管理されたビルド、アーティファクトの体系的な署名、完全性検証（ハッシュ）、デプロイ版追跡（日付、所有者、フィンガープリント）。公開/デプロイ権限を制限し監査する。目的はサプライチェーン侵害リスクの低減と調査の容易化です。
パイプラインが侵害されると、「正当な」リリースに悪意のあるコードを注入し、大規模に配布できるためです。技術アカウント、シークレット、署名キー、リポジトリを保護します。すべてのビルドでSASTを工業化し、アーティファクトとレポートを保持し、本番環境前に明確なリリース承認基準を定義します。「コードのみ」のセキュリティでは不十分です。
原則として、ID管理を集中化（エンタープライズディレクトリ）し、特に機密性の高いアプリケーションや特権アカウントに対してはMFAを含む強力な認証メカニズムを適用します。PowerBuilderアプリケーションでは、これは一貫したIAMアプローチ(集中認証、ロール/権限管理、ログ記録、エビデンス(アクセス レビュー、レポート) の作成機能)に帰着します。
最小権限原則に沿ったロール/権限モデルと、権限の完全かつ実用的な可視化機能が必要です。定期的なアクセスレビューを実施し、例外を処理し、承認証拠を保持します。「権限マトリックス」（または同等のもの）は監査を簡素化し、レビューを迅速化します。
SoDは、互いに矛盾する権限（例：支払いの作成と承認、管理と監査）を1人が保持することを防止します。内部不正リスクを低減し、コンプライアンスを強化します。PowerBuilderアプリケーションでは、役割のモデリング、SoDルールの定義、競合の検出、是正、監査証拠の保持を意味します。
まず適用される基準と範囲を定義します。次に要件を測定可能な統制と証拠（スキャンレポート、ログ、アクセスレビュー、権限マトリックス、SoDルール、署名手順、TLS設定など）に変換します。最も有用な成果物は、各監査ごとに再利用可能な「要件→統制→ツール→証拠」のマッピングです。

ツールとリソース

PB PowerBuilder

VE Visual Expert

VG Visual Guard

参考文献 – 本ガイドで引用した情報源