5分で読めます

AWSコンプライアンスを維持する方法

Amazon Web Services (AWS)は、ISOやSOC 2などへの準拠の認定を受けています。しかし、AWSにデータを格納する方法が常に準拠しているとは限りません。

ビジネスがクラウドに移行し続けている中、データ セキュリティや規制準拠は非常に重要になっています。幸いなことに、オンデマンド クラウド コンピューティング プラットフォームであるAmazon Web Services (AWS®)は、ISO、PCI DSS、SOC 2などの規制への準拠の認定を受けています。しかし、これは、AWS内にデータを格納する方法が準拠しているということではありません。セキュリティと同様に、コンプライアンスは責任共有モデルに分類されます。すなわち、AWSそのものはホスト レイヤーおよび物理インフラストラクチャに適用される規制に準拠する責任を負うのに対し、AWSユーザーはサービスの使用、アプリケーションの利用、クラウドへのデータ保存の方法に適用される規制に準拠する責任を負います。

従来、ITインフラストラクチャでのコンプライアンスの管理はどうなっていたかを確認してみましょう。組織のコンプライアンス チームは、組織のすべてのITリソースのインベントリを作成していました。次に、チームは規制の対象となるデータを含むすべてのリソースを確認し、既存の制御と対応する規制要件を結び付けて、コンプライアンスを証明していました。

しかし、AWSの場合、手作業によるコンプライアンス管理では不十分です。開発者は新規リソースを導入し、インフラストラクチャに迅速に変更を加えることができ、多くの場合、変更はセキュリティ チームやコンプライアンス チームのチェックを受けずに実行されます。また、組織がある日のコンプライアンスを証明できても、2週間後、または24時間後でさえも準拠し続けているわけではないことが、事態をさらに複雑にしています。クラウドでは、「ある時点」でのコンプライアンスはすぐに無意味になります。

AWSコンプライアンスを維持するには、新たなアプローチが必要です。DevOpsチームが「継続的なデリバリー」や「継続的なイノベーション」をありふれたIT言語にしたように、「継続的なセキュリティ」や「継続的なコンプライアンス」について頻繁に議論する必要があります。

良い点を挙げれば、従来のデータセンターでのコンプライアンス管理とは異なり、AWSインフラストラクチャではプログラムを使ってセキュリティやコンプライアンスに自動的に対処することができます。クラウド プロバイダAPIを利用できるようになって、セキュリティの自動化のまったく新しい時代が始まりました。AWS Configによって、組織は、AWS APIを使用してインフラストラクチャのメタデータにアクセスし、新たな変更がコンプライアンスの問題をもたらしているかどうかを継続的に監視し、測定できます。

継続的なコンプライアンスのためのAWS Configの使用

AWS Configを使用すると、環境を継続的に監視して、1つのダッシュボードで設定変更および必要な設定ルールへの準拠を確認し、リソース関係の表示および管理をすべて行うことができます(図1を参照)。

 

図1: AWS管理ダッシュボード

次の2つの方法で、継続的なコンプライアンスのためにAWS Configを使用できます。

オプション1:  Simple Notification Serviceを使用して、手作業で修正します。環境内で何かが変更され、組織のルールに準拠しなくなると、SNSでアラートがトリガーされます。これにより、問題の発生後ただちに手作業で修正できます。

オプション2: AWS Lambdaを使用して、自動修復します。環境内での変更により、コンプライアンス違反が発生すると、Lambda関数がトリガーされて自動修正されます。例: Configルールでは、VPCフロー ログを常に有効にするように定められています。誰かがフロー ログを無効にすると、LambdaはAPIアクセスを使用して再度有効にします。

 

AWS Configのしくみを表す図

図2: AWS Configのしくみ

AWS Configにより、APIを介して管理する、カスタマイズ可能な事前定義されたルールが提供されます。管理者はチームおよび組織固有のConfigルールを記述して、より包括的なコンプライアンス レポートを作成することもできます。カスタムAWS Configルールの選定されたコミュニティ リポジトリについては、ここをクリックしてください。

AWSサービスを使用してコンプライアンスを確保

前述したように、責任共有モデルに従って、AWSは実行されているクラウド インフラストラクチャ ワークロードのセキュリティとコンプライアンスに責任を負い、ユーザーはワークロードそのもののコンプライアンスに責任を負います。ただし、AWSには、コンプライアンスを確保するための複数のツールが用意されています。以下に例を示します。

  • PCI DSS要件8: アプリケーション所有者に、システム コンポーネントへのアクセスを識別して認証するよう求めます。AWS Cognitoは、ユーザーおよび他のAWSサービスの認証と認可の設定をサポートする認証サービスで、一般に、この要件を遵守するために使用されます。 

  • PCI DSS要件11: ネットワーク リソースおよびカード会員データへのすべてのアクセスの追跡およびモニタリングについて述べています。これは、CloudWatchやCloudTrailなどのモニタリング ツールを使用して行うことができます。 

きめ細かなレポート

クラウド環境が発展し、組織への規制が厳しくなると、よりきめ細かなAWSコンプライアンス レポートが必要になります。たとえば、AWS環境を特定のコンプライアンス規制に紐付ける方法、またはチームおよびAWSアカウントごとに異なるコンプライアンス ビューを有効にする方法を知りたいでしょう。

このような場合に、サードパーティのAPIベースのコンプライアンス ツールが役に立ちます。このツールを使用すると、クラウド構成の変更をリアルタイムで継続的に監視して、クラウド構成をISO、SOC 2、HIPAA、PCI DSS、NIST、GDPRなどの規制の事前作成済みコンプライアンス テンプレートに紐付けることができます。適切なコンプライアンス ツールを使えば、容易にコンプライアンス レポートを生成し、監査担当者、顧客、利害関係者にワンクリックでコンプライアンス体制をデモできます。適切なツールを選択するガイドラインについては、このブログ記事をご覧ください

この問題の詳細については、eブックContinuous Monitoring and Compliance in the Cloudをダウンロードしてください。