クラウドネイティブを学ぼう！

AWS クラウドセキュリティのベストプラクティス

SHARE:

アマゾン ウェブ サービス（AWS）は、長年にわたり最も人気のあるパブリック クラウド プラットフォームです。しかし、この 10 年間で、マネージド コンテナや Kubernetes サービスなど、さまざまな新サービスを展開し、AWS クラウドのセキュリティはさらに複雑化しています。

同時に、ハイブリッドクラウドおよびマルチクラウドアーキテクチャの普及により、AWS を使用する企業は、すべてを単一の AWS クラウド環境で実行していた時には存在しなかった、新しいクラウドセキュリティの課題に直面する可能性があります。

このような状況の変化に伴い、これまで有効だった AWS セキュリティ対策だけでは、AWS のセキュリティ要件をすべて満たすことは必ずしも困難になっています。この記事では、この課題を踏まえ、最新の AWS セキュリティの基本について説明し、コンテナおよび Kubernetes ベースのアプリケーションを含む、AWS で実行されるワークロードのセキュリティを確保するために従うべき AWS クラウドセキュリティのベストプラクティスを紹介します。

AWS の責任共有モデル

AWS セキュリティの計画を立てる最初のステップは、AWS の責任分担モデルを理解することです。他の主要なパブリッククラウドと同様、AWS は共有セキュリティの概念を採用して、AWS が管理するセキュリティリスクと、お客様に対処していただくセキュリティリスクを区別しています。

AWS の共有責任モデルの公式定義は、他の主要なパブリッククラウドほど詳細ではありません。要約すると、「AWS は、AWS クラウドで提供されるすべてのサービスを実行するインフラストラクチャの保護に責任を負い、お客様はそれ以外のすべてを保護する」という概念です。

実際には、AWS はその微妙な違いを明確に説明していませんが、AWS の共有責任は、他のパブリッククラウドが採用しているモデルと実質的に同じです。基本的に、顧客は、顧客が直接アクセスまたは設定できないすべてのクラウドインフラストラクチャは AWS が保護し、それ以外は顧客が保護する必要があることを覚えておくだけで十分です。これは、AWS がクラスタインフラストラクチャを保護する Elastic Kubernetes Service（EKS）などの AWS マネージドサービスの場合も同様です。EKS では、顧客は Kubernetes 環境およびそれにデプロイするアプリケーションのセキュリティを確保する必要があります。

AWS クラウドセキュリティのベストプラクティス

AWS の責任分担モデルを理解したら、次のステップは、お客様の責任範囲である AWS 環境のセキュリティを確保するための AWS セキュリティのベストプラクティスを適用することです。

AWS クラウド環境のセキュリティを確保する方法

ほとんどの場合、AWS クラウドセキュリティの基本的なベストプラクティスは、あらゆるタイプのクラウド環境で適用されるセキュリティプラクティスと変わりません。その中には、以下のものが含まれます。

  • クラウド IAM を使用する：AWS Identity and Access Management (IAM) フレームワークを使用して、AWS 環境で実行されている各ユーザーおよびサービスのアクセス権限を、必要最小限に制限するきめ細かなアクセス制御を設定する必要があります。たとえば、AWS S3 ストレージバケットへのアクセスを特定の IP アドレスの範囲に制限するには、次のような IAM ポリシーを定義します。
{
  "Version": "2012-10-17",
  "Id": "S3PolicyId1",
  "Statement": [
    {
      "Sid": "IPAllow",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
	       "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
         "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
      ],
      "Condition": {
	 "NotIpAddress": {"aws:SourceIp": "54.240.143.0/24"}
      }
    }
  ]
}Code language: JSON / JSON with Comments (json)

また、CSPM セキュリティツールを使用して、クラウドのセキュリティ体制を弱体化させる IAM ポリシーの設定ミスを検出することもできます。

  • クラウド VPCの使用：お客様は、Amazon Virtual Private Cloud（VPC）を使用して、ワークロード用に分離された環境を設定することができます。VPC を作成することで、お客様はネットワークレベルでワークロードを相互に（および VPC の設定に応じて、パブリックインターネットからも）分離することができます。AWS を使用する場合、VPC を使用する必要はありませんが、VPC はセキュリティリスクを軽減するための有用なツールです。
  • クラウドアカウントを賢く管理：1 つの AWS アカウントで展開できるクラウドリソースの数に制限はありません。ただし、アカウントレベルで関連のないワークロードを分離するために、ユーザーや事業部門ごとに別々のアカウントを作成することをお勧めします。複数のアカウントを使用する場合の欠点は、管理が難しくなることですが、AWS Landing Zone などのサービスを利用することで、この課題に対処することができます。
  • クラウドデータの暗号化：AWS S3 などのサービスに保存されているクラウドデータをアクセス制御で保護するだけでなく、デフォルトのサーバー側暗号化を有効にする必要があります。さらに、転送中のクラウドデータを保護するために、クライアント側暗号化を適用する必要があります。
  • 機密データの保存場所を把握する：大規模なクラウド環境では、個人を特定できる情報を含むデータなどの機密データの保存場所を把握しにくくなります。AWS リソースにタグを付けることで、チームが機密性の高いワークロードにラベルを付けることができ、このリスクに対処できます。Amazon は、AWS クラウドに保存されている機密情報を識別できる自動化サービス「Macie」も提供しています。
  • クラウドアクティビティログを検査する：AWS CloudTrail ログに検出メカニズムを適用して、S3、IAM、RDS などのさまざまな AWS サービスにおけるリスクの高い動作を検出します。

AWS クラウドセキュリティのヒント

上記の標準的なクラウドセキュリティのベストプラクティスに加えて、AWS を使用する際にチームが考慮すべき特別なセキュリティに関する注意事項がいくつかあります。

  • レガシークラウドワークロードのセキュリティ確保: AWS は最も古い主要なパブリッククラウドであるため、一部の企業は 10 年以上も AWS を利用しています。これらの企業では、ECS（AWS が Kubernetes ベースのマネージドコンテナオプションを追加する前にリリースした、自社開発のコンテナオーケストレーションサービス）にデプロイされたコンテナなど、必ずしも最新の AWS セキュリティプラクティスに準拠していない「レガシー」クラウドワークロードを実行している可能性があります。チームが AWS を長年使用している場合、使用している AWS サービスの種類を評価し、リソースを最初に設定した際に適用した構成が、現在のクラウドセキュリティのベストプラクティスに準拠しているかどうかを確認することが重要です。
  • AWS セキュリティツールの使用：AWS は、他の主要なパブリッククラウドよりも幅広いネイティブセキュリティツールを提供しています。GuardDuty などの標準的なセキュリティ監視ツールに加え、AWS は独自の CSPM ソリューション、およびワークロードの構成に関するベストプラクティスを推奨するツール Trusted Advisor も提供しています。このように、AWS は特に大規模で複雑なネイティブセキュリティツールセットを備えているため、チームは AWS セキュリティ戦略の一環としてこれらのツールの使用を検討すべきです。ただし、これらのツールの制限、特に、そのほとんどが AWS 環境のみをサポートしている（つまり、マルチクラウドおよびハイブリッドクラウドアーキテクチャではうまく機能しない）という事実を理解しておくことが重要です。また、これらのツールは、Kubernetes のような非常に特殊なタイプの環境の微妙なセキュリティ要件に対応するように設計されていない、一般的なセキュリティソリューションがほとんどです。
  • AWS ハイブリッドクラウドセキュリティ：AWS は、Outposts というハイブリッドクラウドフレームワークを提供しており、これにより顧客はオンプレミスまたはプライベートコロケーション施設にあるサーバー上で AWS サービスを実行することができます。サーバー自体はAWSが提供しますが、この事実にもかかわらず、顧客はAWSが所有するインフラストラクチャの文脈ではAWSが負うべきインフラストラクチャのセキュリティ要件の大部分を負担します。重要な点は、Outpostsを使用してハイブリッドクラウドを構築する場合、AWSがOutpostsで採用している独自のセキュリティアーキテクチャについて十分に理解しておく必要があるということです。

AWS コンテナセキュリティのベストプラクティス

他の主要なパブリッククラウドと同様、AWS もコンテナ化されたアプリケーションを実行するいくつかの方法を提供しています。主な AWS コンテナサービスには、以下のものがあります。

  • Elastic Container Service (ECS)：Amazon が独自に開発したオーケストレーターをベースにした、マネージドコンテナサービス。
  • Elastic Kubernetes Service (EKS)：Kubernetes ベースのマネージドコンテナサービス。
  • Fargate：ECS または EKS によるコンテナのデプロイを簡素化するサービスです。その代償として、ユーザーはインフラストラクチャや構成に対する制御が制限されます。
  • Lambda：コンテナイメージとしてパッケージ化されたアプリケーションを実行できるサーバーレスの関数サービスです。

インフラストラクチャとコンテナのランタイムおよびオーケストレーションレイヤーの両方を自分で設定および管理する場合、コンテナを AWS EC2 仮想マシンに直接デプロイすることもできます。

How to Secure AWS Containers

AWS でコンテナを展開するために使用するサービスによって、コンテナのセキュリティ保護のアプローチは異なります。ただし、使用するサービスに関係なく、いくつかの基本的な AWS コンテナセキュリティのベストプラクティスを適用してください。

  • コンテナイメージの脆弱性をスキャンします。AWS はイメージのスキャンは行いません。
  • 可能な限り、Kubernetes 展開、RBAC ファイル、AWS IAM ポリシーなど、環境に関連するすべての構成をスキャンして、クラウドセキュリティ態勢の問題を検出してください。
  • コンテナオーケストレーションフレームワークで利用できるツールを使用して、環境のセキュリティを確保し、侵害を検出してください。Kubernetes ベースの AWS 環境では、Kubernetes 監査ログ、RBAC、セキュリティコンテキストなどのツールを使用します。

使用するコンテナサービスに AWS の共有責任モデルがどのように適用されるかを理解することも重要です。このトピックには多くの微妙な点や複雑な要素が存在し、特に AWS が EKS のようなサービスを利用するための複数の方法を提供している点（Fargate 経由で管理するか、EKS 直接経由で管理するかを選択できます）を考慮すると、各アプローチが顧客のセキュリティ責任の割り当てに与える影響が異なります。AWS のドキュメントではこれらの詳細を適切に説明していますので、選択したコンテナサービスに適用される AWS のセキュリティポリシーを必ず確認してください。

進化し続ける AWS セキュリティ環境の管理

AWS が市場シェアでクラウドコンピューティングプラットフォームの主流であり続ける限り、AWS ワークロードのセキュリティ確保は、世界中の組織にとって最優先の課題であり続けるでしょう。また、AWS が新しいタイプのサービスを次々とリリースし、それらをハイブリッドクラウドやマルチクラウドアーキテクチャとの統合を容易にするにつれ、AWS のセキュリティはますます複雑化していくでしょう。

幸いなことに、採用する特定の AWS クラウドサービスおよび構成に適用されるセキュリティ上の課題について調査して理解しておけば、AWS のセキュリティ管理は難しくはありません。必要な情報やツールはすでに存在しています。適切なリソースを見つけるだけなのです。