AWSのよくある設定ミストップ10とその修正方法：チートシート

Amazon Web Services（AWS）は引き続き最大のクラウドプロバイダーであり、市場シェアの40.8%を占めています。現在、多くの企業や組織が、インフラの一部、あるいは大部分をAmazon Web Services上で運用しています。AWSは、組織のデジタルトランスフォーメーションの加速とイノベーションの促進に役立ちますが、AWSへの移行ではよくある設定ミスが発生します。

よくある設定ミスは、セキュリティ侵害やインフラのセキュリティギャップにつながり、AWSアカウントで悪意ある攻撃者が何をしたのか、慌てて特定する事態を招きかねません。インフラにこうしたセキュリティギャップが生じるのを防ぎ、潜在的なセキュリティ侵害を回避するため、ここではAWSのよくある設定ミスのトップ10を紹介します。

1. AWSアカウントのメインユーザーとしてルートユーザーを使用する。

2. 有効期間の長いシークレットをアプリケーションのコードベースに保存する。

3. IAMポリシーで「*」権限を使用する。

4. AWSアカウントで許可されていないAWSサービスを使用する。

5. AWSストレージサービスに保存されたデータを暗号化しない。

6. AWSアカウントの監視ツールを有効にしない。

7. セキュリティグループをインターネット上のすべてのユーザーに公開する。

8. すべてのサービスを1つのAWSアカウントに配置する。

9. AWS RDSの安全でないデフォルト設定

10. 削除済みのパブリックAWS S3バケットに紐づいたままのDNSレコード。

以下の設定ミスを回避する方法について、詳しくはAWSセキュリティ設定ミスのチートシートをダウンロードしてご確認ください。

1. AWSアカウントのメインユーザーとしてルートユーザーを使用しない

ルートユーザーは、AWSから提供される管理者権限を持つユーザーです。しかし、ルートユーザーが侵害されると、そのルートユーザーがアクセスできる組織内のすべてのAWSアカウントにアクセスできなくなるおそれがあります。ルートユーザーの代わりに、人間のユーザーにはフェデレーション（AWS Identity Center）を、またはAWS IAMユーザーを使用してください。

ルートユーザーは、アカウント内のすべてのAWSリソースとサービスにアクセスできます。ルートアカウントの認証情報が侵害されると、悪意ある攻撃者が機密性の高いアプリケーションやデータにアクセスし、侵害されたアカウントのデータやリソースを悪用する可能性があります。

ルートユーザーを安全に保ち、悪意ある攻撃者に利用されないようにすることが重要です。フェデレーションやAWS IAMユーザーの使用に加え、ルートユーザーアカウントを保護するために、次の対策も実施できます。

• 自分用のIAMユーザーを作成し、管理者権限を付与する。

• ルートユーザーの認証情報を決して共有しない。

• 可能であれば、パスワードマネージャーを使って強力なパスワードを作成する。

• 多要素認証を必ず有効にする。

• ルートユーザーでログインがあった際に通知されるよう、アラートを設定する。

2. 有効期間の長いシークレットをアプリケーションのコードベースに保存しない

プログラムからAWSを利用するには、プログラムによる呼び出しでIDを検証するためにAWSアクセスキーが必要です。アクセスキーは、アクセスキーIDとシークレットアクセスキーで構成されます。そのため、アクセスキーを持つ人は誰でも、あなたと同じようにAWSリソースにアクセスできます。アクセスキーが侵害されると、悪意ある攻撃者がキーを使って、プログラムから利用可能なすべてのサービスにアクセスできるため、アクセスキーの保護が重要です。

AWSアクセスキーは90日ごとにローテーションし、90日以上使用されていないアクセスキーは削除することを推奨します。可能であれば、アクセスキーをアプリケーションコード、実装用ソフトウェア、クラウドストレージに保存しないでください。

3. IAMポリシーで「*」権限を使用する

私たちのセキュリティは、クラウド環境に実際にデプロイされ、稼働しているものによって決まります。

すべてへの権限やアクセスを付与しないよう、IAMユーザー、IAMロール、グループ、AWSワークロードプロファイル（インスタンスプロファイル）に権限ポリシーを割り当ててください。

問題を未然に防ぎ、場合によっては修正するには、IAM Access Analyzerを利用できます。IAM Access Analyzerでは、次のことが可能です。

• アクセスアクティビティに基づき、最小権限のポリシーを作成する。

• サポートされているリソースタイプを継続的に監視し、レビューする。継続的な監視により、パブリックアクセスやクロスアカウントアクセスを許可しているリソースを特定できます。また、割り当てられた権限が過剰なリソースも特定できます。

IAMポリシーを本番環境にデプロイすれば、ワークロードに必要な権限だけを付与できていると確信できます。

4. AWSアカウントで許可されていないAWSサービスを使用しない

法的要件や技術的要件などのコンプライアンス要件は、業界によって異なります。多くの組織は、業界のコンプライアンス要件を満たすAWSサービスと、そのサービスを利用できる地理的リージョンのリストを作成しています。これにより、組織は事業展開が必要な市場で、業界のコンプライアンス要件を満たしながら、迅速かつ合法的に業務を継続できます。

しかし、こうしたリージョン以外で業務を行ったり、法令やコンプライアンス上の要件に違反するAWSサービスを使用したりすると、組織に多額の罰金が科される可能性があります。

AWSアカウント全体のIAMユーザーとロールのアクセスを管理するための安全策を定めるには、AWS OrganizationsのAWS SCPを使用することを推奨します。

5. AWSストレージサービスに保存するデータを暗号化する

AWSセキュリティに組み込まれた多層防御の考え方の一つは、保存中および転送中のすべてのデータを暗号化することです。組織で管理する暗号化キー（CMKを使用するAWS KMS）で暗号化できます。

インフラやアプリケーションの構築におけるクラウドの導入が進むにつれて、AWSに保存、転送、処理されるデータは必然的に増えていきます。データをプレーンテキストや暗号化されていない形式で利用できる状態にしておくと、悪意ある攻撃者に読み取り、コピー、改ざんされるおそれがあります。こうした事態やその他のセキュリティ侵害を防ぐため、保存中および転送中のデータを暗号化してください。

6. AWSアカウントの監視ツールを有効にする

AWSソリューションの可用性、信頼性、パフォーマンスを維持するには、監視が不可欠です。悪意ある攻撃者がインフラを狙った場合、AWSアカウントでどのような手順が実行されたのかを把握することが重要です。

AWSには、問題の発生を通知し、適切な場合には自動的に対処する監視ツールが複数用意されています。アカウントの状況を把握するために、次のツールを有効にして監視してください。

• すべてのAWSリージョンでAWS CloudTrailを有効にする

• AWSのすべてのリソースとアプリケーションでAWS CloudWatchを有効にする

• 組織のリスクプロファイルによっては、AWS VPC Flow LogsとAWS S3アクセスログの有効化も検討してください。

7. セキュリティグループでインターネットからのトラフィックを制御する

インターネット経由でアクセス可能なリソースをAWSアカウントに作成すると、攻撃のリスクが高まります。悪意ある攻撃者は、悪用できる脆弱性や認証なしでアクセスできるサーバーを探すため、インターネット上のIPアドレスを常にスキャンしています。

セキュリティグループのルールを使用して、リソースへのアクセスを既知のIPアドレスやアプリケーション／ネットワークだけに制限できます。また、AWSアカウントとワークロードの悪意あるアクティビティを監視し、自動修復を行うために、AWS Security HubとAWS GuardDutyの利用も推奨します。

8. すべてのサービスを1つのAWSアカウントに配置しない

すべてのアプリケーションを1つのAWSアカウントでホストすると、悪意ある攻撃者にアカウントへ侵入され、アカウント内でホストしているすべてのサービスや他のアプリケーションを調べられやすくなります。

代わりに、複数のアカウントに分けて管理し、リソースを保護してください。

AWS Organizationsは、複数のAWSアカウントを分けて管理できるAWSのサービスです。AWSのWell-Architected Frameworkを活用してアプリケーションやワークロードを分離すれば、悪意ある攻撃者がAWSアカウントにアクセスした場合の影響範囲を抑えられます。

9. AWS RDSの設定ミスを防ぐ

AWS RDS（Amazon Relational Database Service）のようなマネージドデータベースは、認証を必要としない、またはデータベース管理者のパスワードがデフォルトのままになっているなどの理由で設定ミスが発生し、誰でもアクセスできる状態になることがあります。

多くのアプリケーションでは、個人情報や機密性の高い顧客情報をバックエンドデータベースに保存します。データが危険にさらされる設定ミスを防ぐには、AWS RDSインスタンスのセキュリティグループへのアクセスを既知のIPアドレスだけに制限してください。また、AWS RDSで使用するデータベースインスタンスのデフォルト認証情報も変更できます。

10. 孤立したDNSレコードを防ぐ

Route53のDNS（Domain Name System）エントリに、身に覚えのないものや、パブリックなAWS S3バケットに紐づいていないものがないことを確認してください。

AWSなどのパブリッククラウドプロバイダーで管理・ホストされているウェブサイトでは、孤立したDNSレコードが発生するおそれがあります。ウェブサイトをホストするファイルやサーバーを攻撃者のサーバーに置き換えられると、サブドメインの乗っ取りにつながります。

これを防ぐには、すべての有効なDNSレコードの一覧を管理し、定期的に監査してください。不要になったDNSエントリがあれば、それに関連するリソースも削除されていることを確認します。

さらに、AWS S3バケットが誤ってインターネットに公開されていないか、静的ウェブサイトホスティングが有効なS3バケットが削除されていないかを継続的に監視してください。そのうえで、必要に応じて修復を実施します。この継続的な監視には、自動アラートも組み込む必要があります。

クラウドインフラを保護する

クラウドプロバイダーへの移行には、コスト削減、拡張性、競争優位性、セキュリティの強化、コラボレーションの機会など、大きなメリットがあります。しかし、今回取り上げた設定ミスを避けるには、適切にセットアップする必要があります。アプリケーションのセキュリティ侵害のリスクを減らすことは、開発チームとセキュリティチーム双方の継続的な責任です。Snykがその取り組みを支援します。AWSの設定ミスに関するチートシートで、詳しい情報と修復のヒントをご確認ください。まだアカウントをお持ちでない方は、Snykの無料アカウントを作成するか、デモを予約して、Snykがクラウドインフラの脆弱性の発見と修正にどう役立つかをご覧ください。

チートシートをダウンロード