AWS Audit Manager の新しい共通コントロールライブラリを使用して、リスクとコンプライアンスの評価を簡素化

AWS Audit Manager を利用すると、コンプライアンス要件を AWS の利用状況に関するデータにマッピングし、リスクとコンプライアンスの評価の一環として AWS の利用状況を継続的に監査できます。6月6日、Audit Manager は、事前定義されたマッピング済みの AWS データソースを備えた共通コントロールを提供する共通コントロールライブラリを導入しました。

共通コントロールライブラリは、AWS 認定監査人によって実施された広範なマッピングとレビューに基づいており、証拠収集のために適切なデータソースが特定されていることを検証します。ガバナンス、リスク、コンプライアンス (GRC) チームは、共通コントロールライブラリを使用して、証拠収集のためにエンタープライズコントロールを Audit Manager にマッピングする際の時間を短縮し、情報技術 (IT) チームへの依存を軽減できます。

共通コントロールライブラリを使用すると、同じ共通コントロールに関連付けられた複数のフレームワーク (PCI や HIPAA など) のコンプライアンス要件を 1 か所で表示できるため、複数のフレームワークにわたる監査準備状況を同時に把握しやすくなります。これにより、異なるコンプライアンス標準要件を個別に実装し、異なるコンプライアンス体制のために結果データを複数回確認する必要がなくなります。

さらに、このライブラリのコントロールを使用すると、Audit Manager が追加の AWS CloudTrail イベント、AWS API コール、AWS Config ルールなどの新しいデータソースを更新または追加したり、追加のコンプライアンスフレームワークを共通コントロールにマッピングしたりすると、自動的に改善が継承されます。これにより、GRC チームと IT チームが証拠ソースを継続的に更新および管理するために必要な労力が削減され、Audit Manager がライブラリに追加するさらなるコンプライアンスフレームワークの恩恵をより簡単に享受できるようになります。

例を使用して、これが実際にどのように機能するかを見てみましょう。

AWS Audit Manager 共通コントロールライブラリの使用
航空会社の一般的なシナリオの 1 つとして、機内食やインターネットアクセスなどの顧客の支払いをクレジットカードでのみ受け付けるようにポリシーを実装することが挙げられます。このポリシーを実装するために、航空会社は、IT 運用のために、「customer transactions data is always available」(顧客取引データが常に利用可能) というエンタープライズコントロールを開発します。 AWS 上のアプリケーションがこの新しいコントロールを満たしているかどうかをどのようにモニタリングできるでしょうか?

私はコンプライアンスオフィサーとして、Audit Manager コンソールを開き、ナビゲーションバーから [コントロールライブラリ] を選択します。コントロールライブラリには、新しい [共通] カテゴリが含まれるようになりました。各共通コントロールは、AWS マネージドのデータソースから証拠を収集するコアコントロールのグループにマッピングされ、さまざまな重複する規制や標準へのコンプライアンスの実証をより容易にします。共通コントロールライブラリで「availability」(可用性) と検索します。 ここで、航空会社の期待される要件がライブラリ内の「High availability architecture」(高可用性アーキテクチャ) という共通コントロールにマッピングされていることがわかります。

「High availability architecture」(高可用性アーキテクチャ) という共通コントロールを展開すると、基盤となるコアコントロールを確認できます。ここで、このコントロールは会社のニーズをすべて十分に満たしていないことに気付きました。これは、Amazon DynamoDB がこのリストに含まれていないためです。DynamoDB はフルマネージドデータベースですが、アプリケーションアーキテクチャで DynamoDB が広く利用されていることを考えると、ワークロードが増減したときに DynamoDB テーブルが利用可能になっていることが間違いなく望ましいです。DynamoDB テーブルに固定スループットを設定した場合には、このような状況を実現できない場合があります。

共通コントロールライブラリで、今度は「redundancy」(冗長性) と検索します。 「Fault tolerance and redundancy」(耐障害性と冗長性) という共通コントロールを展開すると、コアコントロールにどのようにマッピングするかを確認できます。そこには、「Enable Auto Scaling for Amazon DynamoDB tables」(Amazon DynamoDB テーブルのために Auto Scaling を有効にする) というコアコントロールがあります。このコアコントロールは、航空会社が実装したアーキテクチャに関連していますが、共通コントロール全体は必要ありません。

さらに、「High availability architecture」(高可用性アーキテクチャ) という共通コントロールには、Amazon Relational Database Service (RDS) のマルチ AZ レプリケーションが有効になっていることをチェックするいくつかのコアコントロールが既に含まれていますが、これらのコアコントロールは AWS Config ルールに依拠しています。航空会社は AWS Config を利用していないため、このユースケースではこのルールは機能しません。また、これらの 2 つのコアコントロールの 1 つは CloudTrail イベントも使用しますが、そのイベントはすべてのシナリオをカバーしているわけではありません。

私はコンプライアンスオフィサーとして、実際のリソース設定を収集したいと思います。この証拠を収集するために、IT パートナーと簡単に相談し、カスタマーマネージドソースを使用してカスタムコントロールを作成します。コストを最適化するために、api-rds_describedbinstances API コールを選択し、収集頻度を毎週に設定します。

カスタムコントロールの実装は、IT チームの関与を最小限に抑えつつ、コンプライアンスチームが処理できます。コンプライアンスチームが IT 部門への依存を軽減する必要がある場合は、DynamoDB に関連するコアコントロールのみを選択するのではなく、2 つ目の共通コントロール (「Fault tolerance and redundancy」(耐障害性と冗長性)) 全体を実装できます。アーキテクチャによっては必要以上のものになるかもしれませんが、コンプライアンスチームと IT チームの両方にとって、加速と、時間および労力の削減は、既存のコントロールを最適化するよりも大きな利点をもたらすことがよくあります。

ここで、ナビゲーションペインで [フレームワークライブラリ] を選択し、これらのコントロールを含むカスタムフレームワークを作成します。その後、ナビゲーションペインで [評価] を選択し、カスタムフレームワークを含む評価を作成します。評価を作成すると、Audit Manager は選択した AWS アカウントとその AWS の利用状況に関する証拠の収集を開始します。

これらのステップに従うことで、コンプライアンスチームは、システム設計と既存の AWS サービスに整合的な実装を使用して、「customer transactions data is always available」(顧客取引データが常に利用可能) というエンタープライズコントロールに基づいて正確にレポートできます。

知っておくべきこと
共通コントロールライブラリは、AWS Audit Manager が提供されているすべての AWS リージョン で現在利用可能です。共通コントロールライブラリの使用に追加コストはかかりません。詳細については、「AWS Audit Manager の料金」をご覧ください。

この新しい機能により、コンプライアンスとリスク評価のプロセスが合理化され、GRC チームのワークロードが軽減されるとともに、証拠収集のためにエンタープライズコントロールを Audit Manager にマッピングする方法が簡素化されます。詳細については、「AWS Audit Manager ユーザーガイド」をご覧ください。

– Danilo

原文はこちらです。