Cloud governance and auditing best practices on AWS

Pulisher : Mass Migration & DR Center ギル・ジュンボム
Description : クラウド使用時のガバナンス維持のための規制の必要性とコンプライアンスおよびリスク管理に関するインサイトを紹介するセッション。

はじめに

クラウドの活用が大きくなるにつれて増えるリソースと権限に対するガバナンス側面の成功事例を確認するために本セッションに申し込みました。

本セッションは、クラウド使用時のガバナンスに関する内容で、ガバナンス維持のための予防的な規制の必要性とそれに伴う規制遵守、そしてリスク管理についてのインサイトが含まれています。

また、規制を設定する際に考慮すべき点と、そのガバナンスを適用した後の修正と監査をクラウドの規模に応じてどのように行うべきかについての内容です。

本セッションで説明しているGRCは、ガバナンス、リスク管理、規制遵守を意味するもので、組織を安全かつ円滑に運営する戦略を意味します。AWSを使用する方法は、基本的に会社が強制する責任規定を遵守する範囲内で定義された後、適用する必要があります。

ADS(AWS Application Discovery Service)を通じてクラウドに移行した場合を例に挙げると、GRC(governance, risk, and compliance)を定義する時の普遍的な問題点を見つけることができます。

まず、クラウドリソースに対する可視化が不足しているという問題があります。クラウドで使うインスタンスは開始と中断を繰り返すため、このような可視化は重要な問題ですが、一つのアカウントでログインした時、権限の問題でアクセスしたり、見ることができないインスタンスが発生するため、オンプレミス環境で提供されるCMDBを使う時とは違う問題に遭遇します。

次に、RDSやS3のようなクラウドデータベースサービスを使用する際にもデータセキュリティ規制の問題が発生します。クラウドで定義される規制は従来の方式より大きなリージョンで提供されるため、このような部分も考慮しなければなりません。 この他にも、サードパーティの技術を使用した場合も考慮しなければなりません。

しかし、通常、クラウドユーザーは、クラウドでの規制は多くのことを考慮する必要がなく、自動的に設定されると誤解しています。 しかし、クラウドでのセキュリティ規制は、このような規制モデルに対するユーザーの理解が必要な部分です。

AWSの全体的な規制がどのように行われるかを知ることが重要で、そのためにはAWS artifactを使用してISVセキュリティとコンプライアンスレポートを見ることをお勧めします。 また、AWSにはshared responsibility modelという共同責任モデルが存在しますが、これに対する理解が先行することをお勧めします。

どのようにすれば、監査を行うスタッフと現在のワークロードに対する規制政策がどのように行われているのか、コミュニケーションすることが重要な論題だと思います。これに対する質疑応答の内容を共有します。

*(質問1)リスク管理に苦労しており、コントロールタワーを使用するよう説明されていますが、コントロールタワー自体に限界があるようです。 また、私たちはアーキテクチャがよく設計されたマルチアカウント環境を検討しています。

*回答1）AWS Control Towerを設定すると、規制ポリシーに対して追跡した結果を統合的な方向のログを通じて確認することができます。 また、中央化されたハブがあるため、それぞれのアカウントがどのような活動をしているのかを可視的に確認することができます。

AWSの共同責任モデルについて説明します。 このモデルは、AWSとクラウドを使用する顧客がそれぞれクラウドのどの部分に責任を持ち、その責任がどのように共有されているかを示しています。

まず、顧客はクラウド内のセキュリティに責任を持ち、AWSはクラウド自体に責任を持ちます。AWSはCompute、ストレージ、データベース、ネットワークなどのソフトウェア、そしてリージョン、可用性領域、エッジロケーションなどのハードウェアおよびAWSグローバルインフラに関する責任を負っています。

これに備えて、顧客は顧客自身のデータとプラットフォーム、アプリケーション、アクセスに対する管理に責任を負わなければならず、OS、ネットワーク、ファイアウォールの設定なども規定を遵守して管理しなければなりません。 また、顧客が管理するデータを暗号化したり、データの統合的な認証に対する設定が必要です。 また、ファイルシステムやデータのようなサーバー側での暗号化やネットワークに対する暗号化や統合管理、認証管理もセキュリティ設定のための一つの方法でなければなりません。

また、お客様はセキュリティ上の欠陥を引き起こすリスクに対して予防的な解決策を見つける必要があります。

AWS Control Towerにより、プロアクティブな規制設定を迅速に開始することができます。

AWS OrganizationsはAWSのワークロードが拡張される環境を管理することができ、コントロールタワーを通じてこれらのorganizationsをマルチアカウント設定など様々な方法で管理することができます。

予防的な次元の方法とリスク発生後の解決方法の両方の管理が必要であり、これはコントロールタワーやAWS Configを通じて可能です。

これらの部分を自動化できる方策が存在しますが、その一つがCI/CDです。CI/CDを通じてインフラやアプリケーションが変更される前にこれをレビューすることで、予防次元の規制を強制することができます。これはAWS ConfigやAWS System Managerを通じて設定が可能です。

特にこのセッションで紹介したいソリューションは、AWS Audit Managerで、効果的な診断をコントロールすることができます。継続的にAWSの使用状況を検査し、これにより顧客のリスク管理と規制政策に役立てることができます。現業では規制に対する迅速なテンプレートを作成する必要があるため、AWS Audit Managerを通じて統合的なビューを確認することが役立ちます。S3バケットに時間ベースの規制結果が更新され、これにより生成されたレポートを確認することで、明確な規制設定と成功的なGRCが可能です。

（質問1） 該当ソリューションに対するフィードバック : AWS Audit Managerを活用しようとしましたが、そのソリューションのUIが直感的でないと感じました。

（質問2） 次のバージョンでは、一つのフレームワークのみを使用できるようにすることはできますか？

（回答2） 現在、100以上の規制フレームワークが存在すると聞いていますが、サポート可能なものは20個に限られています。 しかし、ブログの投稿にあるように、この機能は現在開発中であり、解決可能な方法があります。これにより、個別化された規制ポリシーを作成できるようになります。

セッションを終えて

このセッションを聞いて、AWSでの規制管理を成功させるために、すでにAWSで提供している様々なツールがあることを学び、そのツールを通じてクラウド運営ガバナンスをどのように運営すべきかについてのインサイトを得ました。 特に、AWS Audit Managerを通じてAWSで生成されているGRCに関するレポートを応用し、これをフィードバックして修正し、ポリシーを更新することができるということが魅力的に感じられ、顧客社のサービスの運営を遂行する際にこれを活用することができるという考えを持って、より正確な活用方法について考えてみることになりました。