Amazon Web Services ブログ

大手金融機関におけるセキュリティ・コンプライアンスのためのイベント管理

本投稿では、商業銀行として米国で Top 25 内にランクインしている金融機関であるBBVA USAが、AWS サービスを使用して大規模なイベント管理の仕組みを実装し、クラウド環境に関連する変更イベントを一元管理し、アクションを自動化した方法について紹介しています。一般的に、モノリシック環境でのセキュリティ・コンプライアンスは、管理・監視対象となるインフラストラクチャが少ないため、監視と実施が比較的容易です。それが多くなったとしても、インフラストラクチャをコード化すれば、民主化され分散化されたアプローチによって、コンプライアンスの見落としなく構成の差分管理（ドリフト）と追跡処理を環境に取り入れることができます。

インフラストラクチャの正常な状態を識別し、そこから外れた違反状態を把握することにより、インフラの状態の可視性が確保され、必要に応じて自動修復によって遵守を強制させることが可能になります。このために、セキュリティイベントの通知やベースラインとなる構成定義といった機能を使うことができます。

AWS は、BBVA USA のような企業に、クラウドプラットフォームを効率的に保護するのに役立つサービスを提供しています。BBVA USA は、Amazon EventBridge を使用した標準設計を成熟させ、大規模なイベント管理ソリューションを展開しました。彼らの手法は、セキュリティおよびコンプライアンス関連サービスから出力される、リスクや脅威を意味するイベントを管理・処理するというアプローチであり、いろいろな場面で適用・横展開できるのではないかと思います。

BBVA USA について

米国では、BBVA は 641 の支店を運営しており、そのうち 330 はテキサス、89 はアラバマ、63 はアリゾナ、61 はカリフォルニア、44 はフロリダ、37 はコロラド、17 はニューメキシコにあります。この銀行は、預金市場シェアにおいて、米国の商業銀行の Top 25 内にランクされています。アラバマ（2位）、テキサス（4位）、アリゾナ（6位）では最大クラスの銀行にランクされています。米国では、BBVA は中小企業庁（SBA）によって主要な中小企業の貸し手の 1 つとして認識されています。また、2019年度に開始された SBA ローンの金額では米国全体で 14 位にランクされています。

チャレンジ

複数のサービスをそれぞれに監査する際の管理の複雑さを軽減するために、BBVA USA はイベント管理パイプラインを使用することを決定しました。つまり、CloudTrail、GuardDuty、Macie、AWS Config のような変更イベント/リスクイベントを生成・管理するサービスに対して、イベント処理パイプラインを用意することで、出力されたイベントを、中央管理された運用アカウントに集約して処理できるようにしています。ご存知の通り、CloudTrail は、アカウント内で実行された操作/アクション/API 呼び出しの監査証跡となる詳細なイベント情報をログに記録します。 GuardDuty と Macie は、どちらも機械学習を使用しており、GuardDuty は想定から逸脱したアクティビティ/ふるまいの検知、Macie はストレージから機密データの検出を行います。 AWS Config を使用すると、リソースを分析し、定義された（またはカスタムの）ルールで指定された基準構成からの逸脱状態を検出できます。イベント処理パイプラインがあれば、これらによって検出された非準拠のリソースに対して実行するアクションを定義することができます。

このチャレンジは以下のような形です。

まず、運用アカウントで EventBridge のカスタムイベントバスを作成し、他のアカウントから出力されたイベントに対応して、通知処理やニアリアルタイムでの対処・修復アクションを実施できるようにします。このような道筋が確立されると、AWS Config が非準拠として検出した変更、CloudTrail が検出したリスクの高いイベント、Macie および GuardDuty が検出した結果を EventBridge ルールで判定させて、運用アカウントでのアクションにつなげることができます。

中央の運用アカウントでは Lambda 関数を使い、クロスアカウントでメンバーアカウントへのアクセスを委任するロールを用いて、メンバーアカウント側のインフラ・リソース設定を再変更・修復するための処理を実行できます。この方法により、Lambda のコードをメンバーアカウントレベルで管理するのではなく、中央の運用アカウントに展開できます。AWS CloudFormation で、このソリューションのために必要なリソースを各メンバーアカウントにデプロイできるようになります。メンバーアカウントが作成される時にはこの設計が基本設定として適用されるようにすることができます。

このソリューションで使用されているサービス

アーキテクチャ

以下のセクションでは、中央の運用アカウント、各メンバーアカウント、AWS サービスがどのように相互作用しているかを示しています。

イベント処理パイプラインの基本構造

BBVA US は、運用アカウントの EventBridge 環境にカスタムのイベントバスを配置し、組織内のアカウント（メンバーアカウント）からこのバスにイベントを送信できるように権限を設定しました。この運用アカウントでは、イベントの送信元となるサービスごとに判定ルールを設定できます。これにより、複数の場所で判定ルールを調整する必要がなくなり、すべてのルールを運用アカウントで開発・設定できます。

図1：メンバーアカウントの EventBridge ルールと運用アカウントのイベントバスとの関係性

  1. 組織内の各メンバーアカウントに EventBridge ルールを展開して、高リスクを示すイベントや非準拠を示すイベントをさまざまなサービスから拾いあげます。
  2. 取得されたイベントは、一元管理された中央の運用アカウントのカスタムイベントバスに渡されます。
  3. 中央のイベントバスでは、出力元のサービスごとに判定ルールを実装します。これは、出力元ごとにイベントの出力形式に違いがあるためです。

イベント管理パイプラインにおける入力

セキュリティやコンプライアンスの監視機能を提供する各サービスはメンバーアカウント側で実行されるため、通常はその出力に対して（メンバーアカウント側で）イベントパターン判定ルールを適用して、リスクや脅威のイベントを拾いあげます。これが基本の流れですが、GuardDuty と Macie には委任管理の仕組みがあるため、イベントパターン判定ルールセットをメンバーアカウント側で管理することなく、運用アカウントへ集約することが可能になります。

AWS Config に対しては、非準拠のイベントのみを拾いあげるように EventBridge のルールを設定して、意味のある情報のみに処理をしぼることができます。
CloudTrail は認識された高リスクのイベントに関する洞察を提供します。運用として必要な、でもリスクが高いと思われるリソースへの変更などの API 呼び出しに対して、BBVA USA では CloudTrail による検出イベントを EventBridge に渡しています。その後は、AWS Config に対して行っていることと同じように、イベントパターンのルールによって後続のアクションの必要性を判定しています。

それぞれをもう少し見てみましょう。

運用アカウントを Macie および GuardDuty の委任された管理者として設定すると、これらのサービスから出力されるリスクや脅威のイベントは運用アカウントに集約されます。これにより、イベントルールを運用アカウントに配置でき、メンバーアカウントとの間でルール設定作業を調整する必要がありません。

図2：委任された管理者アカウントとそこに集約されたイベント、および GuardDuty/Macie の関係性

  1. GuardDuty および Macie の管理者機能を運用アカウントに委任します。これにより、サービスの有効性確認やアカウントレベルでのイベント収集が運用アカウントで実施されます。
  2. 委任された管理者アカウントを介して、イベントおよび関連する情報が運用アカウントに集約されます。これには、発信元のアカウント情報を含みます。
  3. 運用アカウントでは GuardDuty と Macie の検出結果をルールと照合します。その結果として後続アクションへ連携します。

次に AWS Config ですが、検出する項目の設定（AWS Config ルール）はメンバーアカウントが作成されるときにデプロイされるように構成できます。検出項目に対応して、EventBridge で非準拠のイベントを拾いあげるイベントパターン判定ルールを用意する（以下のようなもの）ことで自動的に後続アクションに連携させることができます。

{
    "detail-type": [
        "Config Rules Compliance Change"
    ],
    "detail": {
        "configRuleName": [
            "AutomatedResponse_PublicIP"
        ],
        "messageType": [
            "ComplianceChangeNotification"
        ],
        "newEvaluationResult": {
            "complianceType": [
                "NON_COMPLIANT"
            ]
        }
    },
    "source": [
        "aws.config"
    ]
}

図3：AWS Config による検出と EventBridge ルールの関係性

  1. AWS Config によって、コンプライアンス状態が非準拠であることが検出され、通知をトリガーします。
  2. メンバーアカウントには、非準拠の検出イベントをキャッチする EventBridge ルールを設定しておきます。この判定ルールで拾いあげられたイベントが運用アカウントのイベントバスに送信されます。
  3. 運用アカウントのイベントバスにはさらに後続処理のための判定ルールを設定できます。これにより処理に応じてメッセージを引き渡しできます。

運用側での実行

出力イベントはメンバーアカウント側の EventBridge ルールで判定された後、アカウント間をまたいで運用アカウントのカスタムイベントバスに渡され、そこでさらにルール判定して後続処理へと連携します。出力イベントのすべてを無差別に受け入れることで、最初の判定ルールを管理する工数を減らすことができます。中央の運用アカウントに取り込むべき入力を得るために判定ルールを各メンバーアカウント側に配布する必要がなくなります。出力イベントがカスタムイベントバスで集約されることで、メンバーアカウント側との調整なしで、価値の高いセキュリティ・コンプライアンスアラートを追加することができます。また、メンバーアカウント側への実装のためのビルド処理や通知もなくなりますので、実装遅延でイベント取得漏れが起きてしまった、といったこともなくなります。

すべてのイベントを受け入れるための、メンバーアカウント側で設定する EventBridge ルールはこのような形になります。

{
    "source": [ 
	    "aws.config" 
    ]
}

すべてのイベントが運用アカウントに集約された後、EventBridge はイベントをその後のアクションごとに適切なエンドポイントに渡します。連携先がサードパーティのツールの場合、Amazon Simple Queue Service（Amazon SQS）とAmazon Simple Notification Service（Amazon SNS）が手段となります。つまり、連携先ソリューションやユースケースに応じて、プル型またはプッシュ型での連携を行います。例えば、SIEM との統合では、SQS をプル型で中継するキューとして利用します。同様に、HTTPS エンドポイントのあるサードパーティアプリケーションとの統合では、SNS によって連携処理を行うことができます。

自動修復アクションへと連携するケースでは、メンバーアカウントで実施する修復アクションに必要な最小限の権限をもつロールをデプロイします。このロールに対して sts:AssumeRole 権限を持つ実行ロールを用意し、これを使って運用アカウントから AWS Lambda 関数を実行させることができます。こうすることで、必要なアクションがメンバーアカウントで実行されます。各メンバーアカウントに修復処理を分散配置するのとは異なり、集中型アプローチではメンバーアカウント側に配置する必要のあるリソースの数をおさえることができるため、複雑さと管理の作業負荷の低減に寄与します。

図4：EventBridge ルールとそのターゲット、および実行ロール引き受けの関係性

  1. 対象リソースからイベントが出力されます（検出、非準拠、API 呼び出しなどのイベント）。これらのイベントは、EventBridge のイベントパターンルールで判定されます。
  2. イベントメッセージは運用アカウントの EventBridge カスタムイベントバスに送信されます。そこで、すべてのイベントに対してサービスごとに設定されたルールで判定が行われます。
  3. ルールによる判定で、SQS、SNS、Lambda などのサービスへ連携します。
  4. このイベント管理の仕組みの結果として Lambda が呼び出される際、運用アカウントで実行ロールを引き受けます。ロールは、メンバー側アカウントに対するクロスアカウントロールを引き受けます。
  5. メンバー側アカウントにデプロイされているロールは、修復処理などの特定用途のアクションを実行するための最小限の権限として設定することをおすすめします。

 

AWS CloudFormation を使えば、自動デプロイを有効化したサービスマネージド型の StackSets を実装できます。これによって、メンバーアカウントが作成される際に標準となるベースラインの権限の適用が保証されます。つまり、新しいアカウントは、すでに確立・展開されている EventBridge ルールとすぐに連動可能になることを意味します。

図5：メンバーアカウント、StackSets、および EventBridge ルールの関係性

  1. メンバーアカウントは、作成されると適切な組織単位（OU）に設定されます。
  2. AWS CloudFormation StackSets が、指定された OU のサービスマネージド型のロールを使用して自動デプロイされます。
  3. これらの StackSet インスタンスによって、EventBridge ルールおよびその他のサポートリソースがデプロイされます。

 

まとめ

判定されたアクションでは、必要に応じて、ファンアウトアーキテクチャを使用して複数の連携対象にアクションのためのシグナルを送信できます。この投稿で説明した仕組みによって、検出されたイベントが単なる通知から修復処理へ、または情報の取り込みを経て分析ソリューション連携へと進化します。BBVA USA は、AWS サービスを使用して、リスクや脅威のイベントに対する応答のフローを一元化および自動化しました。EventBridge を使用することで、委任管理の仕組みをもつ AWS サービスも、他の実装パターンが求められる AWS サービスも、同じ標準化されたアプローチで出力イベントを集約することができます。

著者について

Neel Sendas は、Amazon Web Services のシニアテクニカルアカウントマネージャーです。Neel は、エンタープライズのお客様と協力して、ビジネス目標を達成するためにクラウドアプリケーションを設計、展開、およびスケーリングします。彼は機械学習の愛好家でもあります。お客様対応をしていない時間は、ゴルフとサルサダンスに勤しんでいます。

 

 

John は BBVA のクラウドセキュリティマネージャーです。既存のクラウド環境でクラウドネイティブツールとサードパーティツールを実装および運用し、新しいツールとサービスの戦略を構築しました。AWS をいじったり、体験についてのブログ投稿を書いたりしていない時間は、科学ドキュメンタリーを楽しんだり、新しい調理技術を学んだりしています。

 

 

原文はこちらです。