AWSにおけるAmazon S3のセキュリティとコンプライアンスを理解する

クラウドコンピューティングにAmazon Web Services（AWS）を利用している組織では、Amazon S3（Amazon Simple Storage Service）を頻繁に利用していることでしょう。AWSが2006年に提供を開始した最初期のクラウドサービスの一つであるオブジェクトストレージサービスは、使いやすさ、信頼性、拡張性の高さから、非常に多くの支持を集めています。

しかし、S3リソースの設定を誤ると、重大なセキュリティインシデントやコンプライアンス違反につながる可能性があります。S3の設定ミスによる大規模なデータ侵害は、今もたびたび報道されており、今後も発生するでしょう。S3バケットのアクセス権限ポリシーや暗号化設定にわずかな誤りがあるだけで、機密データが悪意ある第三者の手に渡るおそれがあります。

見出しの書き方にかかわらず、こうした事例で責任があるのはAWSではなく、クラウドを利用する顧客です。AWSはクラウドセキュリティの共有責任モデルにおいて、自らの責任を確実に果たしてきました。しかし、S3の設定ミスによって自らに損害を与え、組織がニュースになる事態を防ぐことはできません。

Amazon S3の利用はコンプライアンス要件に左右される

HIPAA、PCI、SOC 2、GDPR、NIST 800-53などのコンプライアンス基準が適用される組織では、いずれの基準にも、S3（および組織で利用している可能性の高い他の多くのAWSサービス）の使用や設定を規定する管理策が含まれていることを理解しておきましょう。該当する基準が組織やワークロードに適用されない場合でも、AWSを安全に利用するための指針として、AWS CIS Benchmarkの採用を強く検討してください。

Amazon S3バケットのアクセス制御を維持する

S3に関連するデータ侵害の多くは、アクセス権限ポリシーの設定ミスが原因です。新しいS3バケットを作成すると、デフォルトのアクセス権限ポリシーは「プライベート」に設定されますが、リソースの運用中に変更されることがあり、実際によく起こります。開発者がアプリケーションやインフラを更新したり、新しいサービスを追加したりすることで、クラウド環境は時間とともに変化します。こうした更新の際に、アクセス権限ポリシーが意図せず緩和されたり、無効化されたりすることがあります。

S3リソースとそのアクセス権限ポリシーを監査し、安全に設定されていることを確認してください。また、CloudTrailを使って設定の変更を追跡しましょう。機密データを含むS3バケットには、Fugueのような製品の導入を検討してください。追加のコードやスクリプトを作成することなく、確立した安全な設定ベースラインからの「ドリフト」を検出し、修正できます。

AWS CIS Benchmarkは、S3の設定と利用を規定するコンプライアンスフレームワークの好例です。CIS 2.6では、バケットのアクセスログ記録を有効にすることが求められています。3.8では、すべてのバケットポリシー変更について、ログメトリクスフィルターとアラームを有効にすることが求められています。最後に、機密データを含むS3バケットがインターネット全体に公開されていないことを確認してください。代わりに、認証済みユーザーのみにバケットへのアクセスを許可するAWS IAMポリシーを作成しましょう。

暗号化でAmazon S3のデータを保護する

Amazon S3リソースの安全なアクセス権限ポリシーを維持することは必須ですが、不正アクセスした第三者にデータを読み取られないよう、暗号化が常に有効になっていることも確認する必要があります。ここでも、S3リソースを監査して暗号化が有効であることを確認し、暗号化の無効化を含むリソースの変更をログで追跡しましょう。

ここでも、コンプライアンスフレームワークが適用される可能性があります。たとえば、NIST 800-53のSC-13「暗号による保護」では、該当する場合に暗号化を実装することが組織に求められています。また、SOC 2のCC 6.1では、保存データの保護に使用する他の対策を補完するために暗号化を用いることが求められています。

つまり、AWSのセキュリティとコンプライアンスを担うのはあなたです！

組織によって異なりますが、AWS上の重要なデータのセキュリティに対する責任は、通常、クラウドセキュリティエンジニア、DevOpsエンジニア、コンプライアンスアナリスト、またはクラウドアーキテクトが担います。クラウドセキュリティの責任を一部またはすべての担当者が共有する場合もあります。そのため、効果的な連携が不可欠です（これは「DevSecOps」と呼ばれることがよくあります）。

役職や肩書きにかかわらず、AWS環境のセキュリティとコンプライアンスに責任を負うのであれば、その重要な役割の一つは、重要なS3リソースが適切に設定され、リソースの存続期間を通じてその状態が維持されるようにすることです。

最初の役割：S3の設定がポリシーに準拠していることを証明する

まだ実施していない場合は、AWS環境にある既存のS3リソースの設定が、適用されるコンプライアンスおよびセキュリティポリシーに準拠していることを証明する必要があります。通常は、AWSコンソールを使った手動の確認や監査ツールを使って、S3リソースの設定を把握するための監査を行います。

すべてのAWS環境を定期的かつ頻繁に監査しましょう。重要なリソースについては、リソースをスキャンし、設定をポリシーと照合して検証するとともに、コンプライアンス違反と全体的なセキュリティ態勢を報告するツールを使って、継続的に監査する必要があります。元のS3設定からの「ドリフト」を検出し、変更がポリシーに違反しているかどうかを判断できるようにしてください。

また、アプリケーションチームやDevOpsチームと緊密に連携し、新しい環境のデプロイや既存環境の更新など、チームの作業が関連ポリシーに準拠していることを確認する必要があります。これは通常、時間がかかり、ミスも起きやすい手作業です。そのため、ソフトウェア開発ライフサイクル（SDLC）の早い段階でポリシーチェックを組み込み、「シフトレフト」する方法を探しましょう。早い段階であれば、是正措置をより簡単かつ迅速に、低コストで実施できます。

2つ目の役割：Amazon S3の設定ミスを特定し、修正する

AWS S3リソースがポリシーに準拠し、安全に設定されていることを確認できました。素晴らしいですね！次は難しい課題、つまりその状態を維持することです。

クラウドインフラリソースの設定ドリフトは広く見られる問題であり、多くの場合リスクを伴います。S3バケットの設定は、AWSコンソールやアプリケーションプログラミングインターフェース（API）から変更でき、さまざまな自動化ツールを使って変更することも可能です。S3の設定は、他の多くのAWSサービスの設定と同様に頻繁に変わり、コンプライアンス違反やセキュリティ上の脆弱性につながることがあります。

AWS環境をスキャンし、S3の設定違反を通知するツールが必要です。静的ウェブサイトのホスティングなど、意図的に公開アクセスを許可しているS3バケットのアラートは無視し、プライベートかつ暗号化されているべきバケットの設定ミスには警告できる機能が求められます。アラートには、手動での修正を容易にするのに十分な設定ミスの情報が含まれている必要があります。

機密データを含む重要なS3バケットについては、手作業のプロセスから脱却し、設定ミスが発生した際に自動で修正することが不可欠です。設定ミスのあるS3バケットなど、クラウドインフラの脆弱性を悪用しようとする脅威自体が自動化されているため、手作業では重要な設定ミスに対する平均修復時間（MTTR）を安全な水準まで短縮できません。また、時間が経つにつれて、自動修復によって多くの時間を節約でき、対象となるクラウドリソースも増えていくでしょう。

AWSの設定ミスを自動で修正する

AWSの設定ミスを効率的かつ包括的に自動修復する方法は、ベースラインを設定し、重要なAWSインフラを自己修復可能にすることです。この方法では、ポリシーに準拠した正常なインフラのベースラインを確立します。ベースラインを確立したら、そこからのドリフトを検出して確認します。重要なリソースでは、ドリフトが発生した際に、確立済みのベースラインへ自動的に戻す必要があります。ベースラインを活用すれば、起こり得る問題を予測してブラックリストを作成する必要がなくなり、セキュリティとコンプライアンスのシフトレフトも実現できます。

Fugueは、自己修復型のクラウドインフラを実現します。詳しくはウェビナーをご覧ください。

3つ目の役割：AWS S3の設定ミスを報告する

定期的なコンプライアンス監査レポートやセキュリティ監査レポートに加え、多くの組織では、Amazon S3のような重要なリソースに関する設定ミスが発生するたびにレポートを作成する必要があります。通常、レポートには次の情報が求められます。

• 影響を受けたリソースと環境は？

• どの設定が変更されたか？

• 設定ミスはいつ発生したか？

• 設定ミスの責任者は誰か？

• この設定ミスによって、どのポリシーに違反したか（該当する場合）？

• 設定ミスはいつ検出されたか？

• 設定ミスはいつ修正され、検証されたか？

• 誰が設定ミスを修正したか（または、どのように修正されたか）？

• 同様の設定ミスが二度と起きないよう、どのような対策を講じているか？

こうしたレポートの作成には大量のログデータを集める必要があるため、ここでも自動化が役立ちます。最後の要件については、自動修復だけが同様の設定ミスの再発を防ぐ方法です。

重要なクラウドリソースの設定ミスに対する平均修復時間（MTTR）を測定し、クラウドセキュリティ対策のレジリエンスを追跡することを検討してください。こうした設定ミスを悪用する自動化された脅威を考慮すると、MTTRが数時間から数日単位になるのは、許容できないほどリスクが高いと考えるべきです。

最後にもう一つ…

クラウドを大規模に運用し、クラウドインフラ環境のセキュリティとコンプライアンスを重視しているなら、Fugueが役立ちます。Fugueを使えば、次のことが可能です。

1. クラウド環境のコンプライアンスを検証し、HIPAA、PCI、SOC 2、NIST 800-53、ISO 27001、GDPRなど、さまざまなポリシーフレームワークに準拠していることを確認できます。

2. クラウドインフラのベースライン設定とドリフト検出により、クラウド環境とその設定を完全に可視化できます。

3. 自己修復型インフラによって、クラウドインフラの設定ミス、セキュリティインシデント、コンプライアンス違反から保護できます。

4. CI/CDとの統合により、開発者が迅速かつ安全に作業できるよう支援し、クラウドインフラのセキュリティとコンプライアンスをシフトレフトできます。

5. 企業全体のクラウド環境で、継続的なコンプライアンスの可視化とレポート作成を実現できます。