AWS Well-Architected Framework のセキュリティの柱をアップデートしました

お客様からのフィードバックと新しいベストプラクティスに基づいて、AWS Well-Architected Framework のセキュリティの柱をアップデートしました。この記事では、セキュリティの柱のホワイトペーパーと AWS Well-Architected Tool の変更点の概要を紹介し、新しいベストプラクティスとガイダンスについて説明します。

AWS は、お客様がセキュアで高パフォーマンス、耐障害性、効率的なインフラストラクチャを構築することを支援するために、Well-Architected Framework を開発しました。Well-Architected Framework は、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化の5つの柱から成り立っており、お客様、パートナー、AWS 内の各チームからのフィードバックを受けて、定期的にフレームワークを更新しています。またホワイトペーパーに加えて、AWS Well-Architected Tool も用意されており、ベストプラクティスに照らし合わせてアーキテクチャをレビューすることもできます。

アイデンティティ管理とアクセス管理の変更点

大きなの変更点は、アイデンティティとアクセス管理、そしてワークロードの運用に関連するものです。セキュリティの柱のホワイトペーパーも、ツールでのレビューも、まずワークロードを安全に運用する観点からスタートしています。この点についてルートユーザーを保護するだけではなく、AWS アカウントの色々な側面から考えてください。そして、AWS から必要に応じて連絡できるように、アカウントの連絡先情報を設定しておいてください。また、サービスコントロールポリシーの機能を持つ AWS Organizations を使用して、ガードレールの発想でアカウントの管理を行うことをお勧めしています。

新しいベストプラクティスは、管理目標を特定して検証することです。この新しいベストプラクティスは、リスク軽減の効果を測定するのに役立つコントロールのリストだけでなく、独自の脅威モデルから目標を作成することです。それに加えて、 パイプラインのセキュリティコントロールのテストと検証を自動化することもベストプラクティスです。

アイデンティティとアクセス管理は、アイデンティティと認証、ヒューマンアクセスとプログラムアクセスで分割せず、より簡単なアプローチとして、アイデンティティとアクセス権限に焦点を当てた２つの質問になりました。これらの質問は、人間と機械を区別しません。AWS 環境、ワークロードをサポートするシステム、およびワークロード自体にアイデンティティとアクセス権限がどのように適用されているかを考える必要があります。新しいベストプラクティスには、以下のようなものがあります。

組織のアクセス許可ガードレールを定義する — 使用できる AWS リージョンの制限など、組織内のすべての ID へのアクセスを制限する共通のコントロールを確立します。
アクセス許可を継続的に削減する — チームやワークロードが決定した必要なアクセス権の情報をもとに、使用しなくなったアクセス権限を削除し、最小権限を達成するためのレビュープロセスを確立します。
緊急アクセスのプロセスの確立する — 自動化されたプロセスやパイプラインで万が一問題が発生した場合でも適切に対応できるように、ワークロードへの緊急アクセスを許可するプロセスを設けておきます。
パブリックおよびクロスアカウントアクセスの分析 — パブリックおよびクロスアカウントアクセスの状態の調査結果を継続的に監視します。
リソースを安全に共有する — アカウント間、または AWS Organizations 内の共有リソースの利用を管理します。

検出の変更点

発見的統制と呼ばれていたこのセクションは、検出と呼ばれるようになりました。このセクションの主な変更点は、イベントへの対応を自動化するという新しいベストプラクティスで、調査プロセス、アラート、修復の自動化についてそれぞれ説明しています。たとえば Amazon GuardDuty のマネージドの脅威検知結果を利用したり、AWS Security Hub foundational best practices を使用したり、Amazon CloudWatch イベント経由でチームメンバーに通知したりAWS Step Functions を使用して、検知したものを調整したり、自動的に修正したりすることができます。

インフラストラクチャ保護の変更点

ネットワーキングとコンピューティングの観点では、わずかな変更点しかありません。このセクションの新しいベストプラクティスは、 ユーザーが離れた場所でアクションを実行できるようにすることです。これは、「データから人を遠ざける」という設計原則に沿ったものです。たとえば、AWS Systems Manager を使用すると、ネットワーク外のポートを開いたり、インスタンスに対話的に接続することなく、EC2 インスタンスでコマンドをリモート実行することできます。これにより、ヒューマンエラーのリスクを軽減することができます。

データ保護への変更点

保存中のデータのベストプラクティスの1つのアップデートは、「データから人を遠ざけるためのメカニズムを提供する」を「データから人を遠ざけるためのメカニズムを利用する」に変更したことです。単にメカニズムを提供するだけでも良いですが、実際に利用されている方が良いのです。

データ保護の中で変わっていない課題として、保存時と通信時の暗号化をどのように強制するかということがあります。通信中の暗号化では、HTTP などの安全でないプロトコルは許可しないでください。セキュリティグループとネットワークアクセスコントロールリスト（ネットワーク ACL）を設定して、安全でないプロトコルを使用しないようにしたり、Amazon CloudFront を利用して、 AWS Certificate Manager (ACM) によってデプロイ、自動ローテーションされる証明書を使って HTTPS 経由のみでコンテンツを提供することができます。デフォルトの EBS 暗号化、AWS Key Management Service（AWS KMS）のカスタマーマスターキー（CMK）を使用した Amazon S3 暗号化、 AWS Config ルールや適合パックを使用して安全でない設定を検知することもできます。

インシデント対応への変更点

セキュリティ柱の最後のセクションは、インシデント対応についてです。このセクションでの新しいベストプラクティスは、 封じ込めと復旧機能を自動化するです。インシデント対応には、すでに計画、導入済みのツール、およびアクセスが含まれているはずですので、次のステップはこれらの自動化になります。このホワイトペーパーのインシデント対応のセクションでは AWS セキュリティインシデント対応ガイドの多くの部分を取り入れて刷新されています。インシデント対応のハンズオンラボ「Jupyter で行うインシデント対応プレイブック- AWS IAM」もチェックしてみてください。このラボでは、Jupyter ノートブックの機能を使用して、AWS API に対して対話的なクエリを実行し、半自動でインシデント対応ができるプレイブックを作成しています。これまでのように、インシデント対応のベストプラクティスは、インシデント対応を計画し、実践することです。これにより、AWS でワークロードを安全に運用しながら、学習しつつ改善することができます。

ツールやホワイトペーパーに関するフィードバックをお寄せいただいたすべてのお客様に、大変感謝しています。AWS Well-Architected Tool でワークロードを見直し、アップデートされた Well-Architected のホワイトペーパーをぜひご確認ください。

新しい Well-Architected のそれぞれの柱についての情報

AWS セキュリティに関するニュース、コンテンツ、新機能のご案内は Twitter でも配信しています。

原文はこちら。翻訳は SA 桐谷彰一が担当しました。

Amazon Web Services ブログ