コンプライアンス エンジニアリング - 手動認証から継続的なコンプライアンスへ

※この投稿は米国時間 2021 年 7 月 31 日に、Google Cloud blog に投稿されたものの抄訳です。

リスク マネジメントとコンプライアンスは、クラウドにおいても従来のオンプレミス環境と同様に重要です。規制対象の業界の企業がコンプライアンス要件を満たせるよう、Google Cloud は生産性向上プロセスの有効性を確保する自動化機能を提供しています。

銀行業界における継続的なコンプライアンス

銀行は世界の富を管理するという重大な責任を負っているため、徹底したリスク管理を行っています。そして、金融規制当局は銀行がリスクを正確に評価し、徹底した管理ができるよう銀行規制を発表します。銀行は情報技術（IT）に大きく依存しているため、この規制は銀行内での IT の使用も対象としています。

規制対象の業界では一般的に、導入した IT 資産が規制を遵守し、管理されたセキュリティ体制を備え、企業のリスク許容度を満たすことを確実にするために、拡張されたガバナンス フレームワークを備えています。新しいアプリケーションを本番環境にデプロイする前に、IT アプリケーションのオーナーは、必要な規制上の証拠を揃えるために、通常、数か月の期間を予測しています。コントロールの質問は通常、従来のオンプレミス テクノロジーのアーキテクチャに基づいており、クラウド固有のテクノロジーとの関連性が欠如していることが多いため、クラウド自動化機能を使用してもメリットがありません。たとえば、多くの銀行の現行の IT モデルは、月に数回の変更を想定して構築されていますが、クラウドでは毎日数百回の変更を行うことができます。

トップレベルの規制を受ける金融機関が、変革を始める前にどのような課題を抱えていたのかを聞いてみましょう。

「単に当銀行が使用するテクノロジーが大きく異なるというだけではなく、強力なコントロールとコントロール ソリューションをクラウド プラットフォームに組み込むという、基本的なアプローチでした。Google Cloud を採用したことによるオペレーション モデルの変更により、現在のコントロール セットの中の一つひとつのコントロールを見直す必要があることが明らかになりました。」- ドイツ銀行運用準備状況担当者 Bill Walker 氏

以下のセクションは、セキュリティおよびコンプライアンスの最高責任者が現在の資産を評価し、一連の重要な推奨事項に基づいて IT 関連リスクの変革を開始するのに役立ちます。

オンプレミスからクラウドへのプロセスの転換

既存のコントロールの背景にある目的は今のところ適切かもしれません。しかし、運用リスクに適切に対応するためには、定義と認証を進化させる必要があります。厳格な管理環境に加えて、スピードと市場投入の能力が求められることから、クラウドベースの環境における効果的な管理と自動認証の重要性が強調されています。規制された環境でのより広範なデジタル トランスフォーメーションについては、Google Cloud のホワイトペーパー「クラウドにおけるデジタル トランスフォーメーションのリスク ガバナンス」をご覧ください。

本題に入る前に、ここではいくつかの用語を定義しておきます。コントロールの核となるのは、さまざまなタイプのリスクを管理することです。セキュリティ コントロールは、情報の機密性、完全性、可用性が損なわれるリスクに対処することに重点を置いています。コンプライアンス コントロールは、業界の法律、規制、および内部ポリシーに従って行動しないリスクに対処することに重点を置いています。コントロールの実現は、1 つまたは複数の基本的なコントロールの質問を証明することで達成されることがよくあります。

コントロールのグループ化

クラウドの高度に統合されたサービスにより、アプリケーション オーナーは、アプリケーションに関連するコントロールに集中できます。一方で、基盤となるプラットフォーム サービスは、ワークロードの風景全体について、すでに一元的に証明されている必要があります。

以下のコントロールのグループ化の提案は、すべてのワークロードが証明しなければならないコントロールの削減につながります。コントロール オーナーとエンジニアリング チームは、自分たちの専門分野のコントロール グループに集中できます。言い換えれば、対応するアプリケーション エンジニアは、プラットフォーム層への実装を完全に認識している必要はありません。

全社的なコントロールのグループは、クラウド プロバイダとクラウド サービスを評価するベンダーリスク評価の一部です。これらのコントロールの証拠は、企業内でサービスがどのように構成され、使用されるかに影響されません。具体的な例としては、プロバイダの従業員の入社と退社プロセスが挙げられます。

プラットフォーム全体のコントロールのグループは、このランディング ゾーン上で実行される各ワークロードに自動的に適用されます。具体的な例としては、監査ログ（組織およびフォルダレベル）、特権ユーザー アクセス管理（PUAM）、または保存データに使用される暗号化タイプが挙げられます。組織のポリシーを使用することで、GCP のリソース階層全体の構成を定義できます。

ワークロード固有のコントロールのグループは、アプリケーション レベルで証明され、カスタム アプリケーションのアーキテクチャに焦点を当てています。証拠となる構成は、デプロイされたアプリケーションに固有のもので、使用する認証プロバイダ、ユーザー アクセス管理、障害復旧の設定などが含まれます。

大規模なランドスケープでは、ワークロード クラスのグループを追加することで、処理されたデータの機密性やインターネットに面したネットワークなどの共通点によってアプリケーション固有のコントロールをクラスタリングできます。

グループ化することで、自動化を製品化の適切な段階に配置できます。企業全体のコントロールは、多くの場合、一度しか評価されないため、自動化への投資には大きな見返りがありません。プラットフォーム全体のコントロールは、セキュリティ管理体制管理システムで自動化され、すべてのアプリケーションで継続的かつほぼリアルタイムのコンプライアンス監査を可能にする必要があります。ワークロードまたはワークロード クラス固有のコントロールは、継続的インテグレーション / 継続的デプロイ（CICD）パイプラインの一部として自動化する必要があります。

クラウドの適切性の評価

クラウドには、IT をより安全にするための多くの機能がありますが、多くの企業は、クラウドの導入を技術的負債への対処とリスクの低減を一度に行う機会と考えています。ワークロードをクラウドに移行することは、管理すべきリスクの種類に影響を与えますが、安全性の低下を招いてはなりません。そのため、既存のコントロールとコントロールの質問を見直し、効果的なものにすることが重要です。

これを実際の例で説明すると、既存のオンプレミスのコントロールでは、失敗した場合のロールバック セクションを含むアプリケーション リリースをデプロイするための手動の手順または自動の手順をチェックすることになります。Infrastructure as Code は、アプリケーションのエンドツーエンドのデプロイとロールバックを自動化するものです。このコントロールを証明するには、Terraform スクリプトで十分です。同じ分野の別の例としては、エンジニアの本番環境へのアクセスに関するガバナンス（承認プロセス、アクセス権を持つ人のリストの管理など）は、本番インフラストラクチャへの人間によるアクセスが例外の場合のみになると大きく変わります。

要するに、コントロールとコントロールの質問を次の基準で評価する必要があります。

• 効果的 - コントロールがクラウド環境を正確に証明している

• 調整が必要 - コントロールは適切だが、クラウド技術を反映させる必要がある

• 陳腐化 - コントロールはクラウド環境の評価には有効ではなく、廃止してもよい

公開されているクラウド コントロール フレームワークは、自社の特定のコントロールに組み込み、クラウドの適切性を評価するための強固な基盤を形成します。さらに、コントロール フレームワークのギャップの可能性を特定し、新しい適切なクラウド ネイティブ コントロールを導入できます。

より多くの ops を開発に移行させる

生産性向上のための変革は、技術やコンプライアンスのフレームワークだけではなく、「人々」の問題でもあります。それは、今のプロセスをずっと維持し、強化してきた人々です。コントロール エリアの最終責任者であるコントロール オーナーは、新しいクラウド技術に精通しているわけではないので、少し懐疑的になるかもしれません。変換が成功するか失敗するかは、彼ら次第です。

コントロール オーナーに学習の時間を提供し、テクノロジーに対する自信を持たせ、設計とエンジニアリングのプロセスに最初から参加させ、それぞれの組織におけるクラウド変換のアドボケイトにしましょう。この推奨事項は、オペレーションを開発チームの一員とするという、サイト信頼性エンジニアリングの実践に従ったものです。

その利点は、コントロール オーナーが技術に自信を持ち、自分のコントロールが適切に評価されていることを確信できることです。コントロールはさまざまな組織（セキュリティ、事業継続、規制など）に由来するため、それぞれの組織でコントロールの変更を主張します。

コントロールのトレーサビリティを持ち、合否基準を明確にする

コントロールの質問から、コントロール、ポリシー、規制までの明確なトレーサビリティを確保することで、解釈を整理し、大規模な自動化が可能になります。

当たり前のことのように聞こえるかもしれませんが、製品化のプロセスは年々増加しています。そのため、どのようなリスクを評価しなければならないのか、提供されたエビデンスがどのように使用されているのかが完全にはわからないことがあります。アプリケーション オーナーができるだけ早く本番環境に移行できるようにするためには、コントロールを自動化することが避けられません。自動化は、解釈の余地のない明確な合否基準があって初めて可能になります。歴史的な理由で明確なトレーサビリティを持たずに存在するコントロールをフィルタリングし、潜在的に欠落しているコントロールを特定できます。

銀行は、世界の富を管理するという大きな責任を負っているため、リスク管理に優れています。銀行は、クラウドへのデジタル トランスフォーメーションに伴い、既存のコントロール プロセスを適応させ、認証を自動化するという課題に直面しています。コントロールを理解し、新しい IT 配信のパラダイムに合わせて効果的にし、移行を促進するために自動化し、継続的なコンプライアンス モデルに移行しなければなりません。

以降の連載記事では、具体的な自動化の事例を取り上げ、「Infrastructure as code」と「Compliance as code」により、規制当局による監査が、周期的な評価から IT アセットのライフタイム全体を通じた継続的な体制管理へと移行する様子を紹介していきます。

-テクニカル アカウント マネージャー Florian Graf