「コンプライアンス自動化標準ソリューション（COMPASS）, パート1 パーソナと役割」
「コンプライアンス自動化標準ソリューション（COMPASS）, パート1 パーソナと役割」
（注意：このシリーズのすべての記事のリンクは、この記事の結論にあります。）
これは、組織やクラウドプロバイダーが持続的なコンプライアンスを達成しようとする際に直面する課題を示すブログ投稿シリーズの最初のパートです。このシリーズでは、オペレーショナルで拡張性のある、効果的なエンドツーエンドのソリューションに向けて、主要な概念、技術、業界標準を提供します。
まず、コンプライアンスのペルソナとその役割とアクションについて紹介します。ペルソナ、役割、およびニーズを理解することは、ガバナンス、リスク、およびコンプライアンス（GRC）の自動化の設計およびアーキテクチャ上の意思決定に不可欠です。これについては、後続のブログ投稿で詳しく説明します。
このシリーズの第2のブログ投稿では、企業全体のコンプライアンスプロセスで取り扱われるコンプライアンスアーティファクトと、それらの人間による消費およびプログラム的な有効化（コードとして）のデザインについて説明します。
- DeepBrain AIレビュー：最高のAIアバタージェネレーター？（2023）
- PaaS4GenAI Oracle Integration CloudからIBM Cloudプラットフォーム上のGenerative AI (WatsonX)との接続
- 「プロンプトエンジニアであるということの体験」
後続のブログ投稿では、階層型のガバナンス、リスク、およびコンプライアンス（GRC）ソリューション、ポリシーオーケストレーターとポリシーバリデーションオーケストレーターのさまざまなタイプ、ポリシーバリデーションツールとオーケストレーター間の相互運用性を可能にする標準化されたエクスチェンジプロトコル、ポリシーオーケストレーター向けのAIベースの規制のクロスウォークサポート、およびいくつかの特定のポリシーバリデーションの自動化技術について説明します。お楽しみに。
持続的なコンプライアンスの重要性
現在、規制コンプライアンスは企業の負担となっています。企業の世界では、断続的な監査からコンプライアンスの継続的な領域に移行し、システムの状態をダッシュボードで簡単に把握できるようになりました。持続的なコンプライアンスを達成するためには、自動化と標準化の両方が必要です。自動化を実現するには、ガバナンスプロセスの分断、組織のポリシーとそれに対応する技術的な実装との間の切断、およびコンプライアンスの実装と測定の複雑さにより、困難を伴います。
システム、API、およびプログラム的なデータ表現に近づくほど、デジタル化と自動化が容易になります。一方、マニュアルプロセスと人間の形式のデータ表現に近づくほど、デジタル化と変換は困難になります。コンプライアンスは、PDFやWordドキュメントによる規制、ガイダンス、および解釈、およびサンプルの証拠を収集しスプレッドシートレポートを作成するマニュアル手順にあります。したがって、コンプライアンスの自動化の取り組みを開始するには、これらのマニュアル、半自動化、および分断された手続きとそれらを支援する要素の理解が必要です。
このブログ投稿では、ガバナンス、リスク、およびコンプライアンス（GRC）管理フレームワークでの関係者とその役割とアクションについて調査します。このシリーズではコンプライアンスに焦点を当てているため、リスクの側面は後で含まれます。次に、これらのペルソナに関連するコンプライアンスアーティファクトを紹介し、自動化を可能にするためにコンプライアンスコードおよびポリシーコードとしての表現を例示します。コンプライアンスアーティファクトの包括的なカバレッジは、次のブログ投稿の主題となります。
コンプライアンスのペルソナ
図1：ガバナンス、リスク、およびコンプライアンス管理フレームワークでのコンプライアンスペルソナのアクション
図1に示すように、ガバナンス、リスク、およびコンプライアンス（GRC）管理フレームワークに関与する主要なコンプライアンス関係者と、これらのペルソナからのアクションの流れは次のとおりです：
- 規制当局は、コントロールやパラメータを持つカタログとして規制、法律、および標準を定義します。また、予め定義されたコンプライアンス要件をベースラインまたはプロファイルに設定します。
- CISOエンタープライズアーキテクト、セキュリティエンジニア、およびコンプライアンスオフィサーは、規制の解釈、環境およびリファレンスアーキテクチャに対してガイダンスを定義し、カスタマイズし、関連付けます。
- コントロールプロバイダ（製品ベンダー、サービスプロバイダ、OSSプロジェクトメンテナーなど）は、規制のカタログのコントロールを製品（ハードウェア、ソフトウェア、サービス、プロセスなど）に実装します。これは、CISOやコンプライアンスオフィサーの解釈とガイダンスに従って、製品の構成パラメータと動作に技術的なルールを適用することで、コントロールの実装方法を宣言するためです。コントロールプロバイダは、各コントロールと技術的なルールのマッピングを示すことにより、コントロールに関連する証拠の性質（スキーマ、テンプレート、APIペイロードなど）も公開する場合があります。
- 技術的なルールは、規制環境またはリファレンスアーキテクチャが規制要件に合致しているかどうかをテストまたは強制するためにチェックまたは実施する必要があります。 コントロールアセッサ（評価ツールベンダー、サービスプロバイダ、OSSプロジェクトメンテナ、およびコンプライアンスエンジニアなど）は、コントロールされた
以下のテーブルでは、エンタープライズ全体のコンプライアンスプロセスに関与するパーソナとそのアクションをまとめています：
表1：エンタープライズ全体のコンプライアンスプロセスにおけるパーソナとそのアクション
主要なコンプライアンスアーティファクト
図2：さまざまなコンプライアンスアーティファクトとそれらのプログラム表現の具体的な例。 PDF形式の規制（上）対コンプライアンスコードとして表現されるコントロールとルール（中）対システムをテストするためのチェックスクリプトとしてのポリシーコード（下）。
図2は、具体例と人間の言語およびコンプライアンスコードまたはポリシーコードとしての表現を持つ主要なコンプライアンスアーティファクトを示しています。コンプライアンスアーティファクトの次の主要な側面を示しています：
- ガバナンス側の規制と規制コントロールは、人間の言語で幅広いステートメントとして表現されます（例：「SC-28情報システムは[機密性；整合性]を保護します。[情報の静止状態]。」）。一方、技術側のテクニカルルールは、コントロールを実装する製品やプロセスの具体的なステートメントとして表現されます（例：「Cloud Object StorageがKYOKで暗号化されていることを確認します。」）。ほとんどの場合、テクニカルルールの文言はコントロールの主張を間接的に反映しており、製品の専門家がルールを生成する必要があり、非専門家やAIによるコントロールステートメントのカバレッジの評価が困難になります。将来のブログでは、人工知能（AI）がクロスウォークを介して規制ステートメントのナビゲーションをサポートする方法を示します。
- これらのコンプライアンスアーティファクトの表現形式は、PDF、フリーテキスト、スプレッドシートからコンプライアンスコード（例：NIST OSCAL）およびポリシーコード（例：OPA – Open Policy Agent）へと進化しています。一方で、カタログ、プロファイル、およびベンダの製品ルールとパラメータの説明の作成と消費を容易にするためにPDF、フリーテキスト、およびスプレッドシートがまだ必要ですが、環境でコンプライアンスツールとサービスがこれらのコンプライアンスアーティファクトを連続的に交換、適用、制御するためにコンプライアンスコードへの移行が必要です。また、規制された環境に展開された製品の技術ルールの連続的なテストには、ポリシーコード（Python、JavaScript、またはOPA Regoのスクリプトなど）への手動の証拠評価プロセスも必要です。次のブログでは、NIST OSCALフレームワークとその標準言語が、典型的なGRCアーティファクトをコードとして表現するためにどのように使用できるかを示します。
- コンプライアンスの自動化と継続的なコンプライアンスを実現するための鍵は、人間の言語での幅広いコントロールステートメントから具体的なテクニカルルールとそれに関連するパラメータとチェックのマッピングのプログラム表現です。この重要なアーティファクトを生成し、GRCフレームワークに登録し、コンプライアンスポスチャを提供するために使用するための複数ステップのプロセスは、GRC Exchange Protocolに関する当社のブログ記事の対象となります。
結論
このマルチブログシリーズの最初のブログ投稿では、ガバナンス、リスク、およびコンプライアンス（GRC）管理フレームワークで期待される主要なパーソナをカバーしました。お気づきの通り、各パーソナには理論的な役割分担に焦点を当てた特定のアクションセットが定義されています。ただし、実際の組織では、個人が複数の役割をカバーする場合もあります。その場合、彼女はそれらのパーソナに関連するアクションをすべて実行するでしょう。
次は何が来るのか？
次のブログ投稿では、エンドツーエンドのコンプライアンスフローで取り扱われるコンプライアンスアーティファクトについての詳細なカバレッジを提供する予定です。規制の表現からコンプライアンスポスチャまでの実際の例を使用して、NIST OSCAL標準を使用したコードとしての表現を提供します。これには、標準（NIST 800-53など）を表すカタログ、ベースラインを表すプロファイル、評価結果などが含まれます。さらに、これらのアーティファクトの相互依存関係とガバナンス、リスク、およびコンプライアンスフレームワークとの関係、およびこのブログで紹介されたパーソナの役割とアクションについても説明します。
以下は、このシリーズの他の記事へのリンクです：
- Compliance Automated Standard Solution（COMPASS）パート2：Trestle SDK
- Compliance Automated Standard Solution（COMPASS）パート3：アーティファクトとパーソナ
- Compliance Automated Standard Solution（COMPASS）パート4：コンプライアンスポリシー管理センターのトポロジ
- Compliance Automated Standard Solution（COMPASS）パート5：ネットワーク境界の欠如はコンプライアンスの欠如を招く
- Compliance Automated Standard Solution（COMPASS）パート6：複数のKubernetesクラスタのポリシーに対するコンプライアンス
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
