AWSの設定ミストップ11を回避する方法

新しいAWSクラウドインフラストラクチャを設定する場合、または権限を付与したり、削除したりするために設定を変更する場合、セキュリティについて常に留意する必要があります。

AWSの責任共有モデルは、ユーザーはクラウド「内」のセキュリティに関して責任を負い、AWSはクラウド「の」セキュリティついて責任を負うことを強調しています。簡単に言うと、これは実行した変更によってデータが公開された場合にユーザーが責任を負うことを意味します。

この記事では、最も一般的なサービスで最も共通する一連の設定ミスについて説明し、インフラストラクチャの変更時に安全を保ち、侵害の可能性を防ぐ方法を提案します。

S3設定ミスのトップ4

1. パブリックバケットまたはバケット内のパブリックオブジェクト

S3をWebサイトストレージに使用するか、静的サイトのホスティングオプションとして使用する必要がある場合、すべてではなくても、それらの一部を公開する必要があります。このプロセスは簡単ですが、誤って実行すると、すべてのデータが侵害されるリスクが生じる可能性があります。このような侵害は過去数年間にわたり広い範囲に影響を及ぼしています。新しいバケットを作成し、それを公開する場合、いくつかのオプションを選択できます。

次のスクリーンショットに示すように、新しいACL、任意のACL、新しいアクセスポイントポリシー、または任意のアクセスポイントポリシーのいずれかを使用して、バケットとオブジェクトへのパブリックアクセスを許可することを選択できます。

アプリケーションに最も適したソリューションを慎重に選択する必要があります。また、バケットに追加した内容は、変更されない限り公開されたままになるため、機密データが公開される可能性があることに注意してください。

2. アクセスログを使用しない

S3アクセスログは簡単に設定して有効にできます。バケットの「プロパティ」タブを参照すると、アクセスログは次のように表示されます。

このログはデフォルトで無効になっていますが、「編集」ボタンをクリックして、保存するログのターゲットバケットを割り当てることですると有効になります。

この設定内容の場合、バケットのアクセスに関する各リクエストのログが記録されます。さらに、これらのログの使用には追加料金がかからないため、特定の状況では非常に有用で、クライアントにS3の請求について説明することにも役立ちます。ただし、これらのログをターゲットバケットに保存すると、通常どおりS3料金が適用され、料金が発生することに注意してください。これらのログはすぐに蓄積する可能性があるため、削除メカニズムの設定が必要な場合があります。

また、ターゲットバケットのログへのアクセスが有効になっていない場合、無限ループが発生し、高額な請求が発生してしまう可能性があるため、注意が必要です。

3. バージョニングとS3ライフサイクルを使用しない

バケットのバージョニングを有効にすると、同じバケット内でオブジェクトの複数のインスタンスを保存できます。この機能が最も役立つ点は、アプリケーションの誤動作や意図しないユーザーアクションからリカバリできることです。

この機能は、「プロパティ」タブに移動してS3コンソールから有効にできます。

簡単に有効にでき、多要素認証 (MFA) の削除も併用して、オブジェクトの以前のインスタンスが意図せずに削除されないようにする必要があります。

この機能の欠点は、あるオブジェクトのあらゆるバージョンに対して、そのオブジェクトと他のバージョン自体の違いだけでなく、オブジェクト全体が格納されることです。これは、S3ライフサイクルの設定ルールを使用することで軽減できます。これにより、設定期間が経過すると最新でないオブジェクトが削除されるように設定できます。また、S3 Glacier Flexible Retrievalなどの手頃な価格のストレージサービスに最新でないオブジェクトを移行して、最新バージョンに置き換えられたときにそれらを削除することもできます。

4. 重大な情報を暗号化しない

機密データを保存する場合は、必ず暗号化してください。暗号化はS3を介してサーバー側で実行するか、ユーザー自身がクラアント側で実行できます。サーバー側で暗号化するほうがはるかに簡単です。これは、オブジェクトのダウンロードまたはコピー時に、Amazonが暗号化、保存、および復号化を処理するためです。これを実行するには、「デフォルトの暗号化」セクションで「編集」ボタンをクリックして、「プロパティ」タブで設定します。

これにより、暗号化に使用するキーを選択できます。SSE-S3キーはS3によって管理されているため、何も操作する必要はありません。SSE-KMSキーはKMSが管理しているため、さらに追加のセットアップが必要になります。

データの機密性が非常に高い場合、保存する前にそれらのデータを暗号化することを推奨します。この場合、キーを紛失すると、オブジェクトを回収したり暗号化を解除したりできなくなるため多少のリスクがあります。このプロセスも広範でセットアップが必要であるため、AWSのドキュメントで実行方法を確認する必要があります。

EC2設定ミスのトップ3

1. パブリックスナップショット、または暗号化されていない共有スナップショット

インスタンスから取得したスナップショットは、デフォルトで非公開になっていますが、この設定が変更される可能性のある2つのシナリオがあります。

最初のシナリオでは、十分な権限（AWS Lambdaなどのサービスも含む）を持つユーザーがスナップショットを公開に変更し、すべてのデータが以前の状態で公開され、破滅的な結果をもたらします。もう1つのシナリオは、暗号化されていないスナップショットを共有する必要がある場合に発生します。この場合、スナップショットの受信者は、そのスナップショットからボリュームを作成できるため、すべてのデータが含まれているインスタンスを起動できます。

いずれの場合でも、スナップショットを暗号化する必要があります。つまり、作成時にインスタンスを暗号化するか、暗号化したスナップショットを作成してから、そのスナップショットから新しいルートボリュームを作成する必要があります。

2. パブリックサブネットに存在するバックエンドインスタンス

データベースやシンプルなAPIなどのインターネット接続が必要でないインスタンスがある場合、それらはプライベートサブネットに保持しておく必要があります。インターネットに接続している状態では、インスタンスのIPに誰がアクセスしているか不明なので、いつトリガーされるかわからない脅威が常に存在します。

プライベートサブネットにインスタンスを存在させるには、IPv4とIPv6の各アドレスから自動割り当てを削除します。これを実行するには、VPCコンソールで「サブネット」タブに移動し、お使いのインスタンスのサブネットを選択して、設定をオフに切り替えます。

3. パブリック/非暗号化AMI

AMIを作成する必要がある場合、別のアカウントの共有が必要な場合もあります。この場合、セキュリティ侵害を防ぐために、慎重にいくつかの対策を採用する必要があります。

最初に、ボリュームを暗号化する必要があります。これにより、ボリュームを含んでいる可能性のあるAMIがデフォルトで暗号化され、データが公開されなくなります。次に、EC2に権限を付与する場合は、AMIの可用性を公開する設定が含まれている可能性があるため注意してください。これは、社内に悪意のあるアクターが存在する場合、またはAWS Lambdaなどのサービスが侵害された場合に問題になる恐れがあります。

最後に、以下のように必ずコンソールを介してAMIを共有し、AMIが外部に公開されてしまう可能性のある事故が発生しないようにする必要があります。

IAM設定ミスのトップ4

1. 多要素認証/キーローテーションの欠如

多要素認証 (MFA) は、アイデンティティ/アクセス管理 (IAM) に追加されるエンティティ（特にユーザー）にとって必須となる必要があります。これにより、キーが盗難される可能性が軽減し、攻撃対象領域の拡大を防ぐことができます。MFAを必須にするには、MFAを有効にするユーザーの「セキュリティ認証情報」タブに移動して設定します。

また、アカウント全体で、アクセスキーのローテーションを適用する必要があります。AWSは自動でキーローテーションを実行できないため、手動で実行することを推奨しますが、このプロセスを自動で簡単に実行できるオープンソースツールがあります。これは、設定時間が経過するとロールで自動的にキーの有効期限が切れるため、IAMユーザーにのみ適用され、ロールには適用されません。

2. ロールを使用しない

アイデンティティおよびアクセス管理 (IAM) を介して、ユーザーに直接ポリシーを添付することで、それらのユーザーに権限を付与することを選択できます。ただし、誤った権限を誤ったユーザーに付与する可能性があるため、大規模で重大なインフラストラクチャでは不適切な慣行です。また、このような権限を削除することを忘れると、その権限が永久に残ることになります。

権限を付与する際に優先する方法としてロールを使用することで、キーの有効期限を自動で取得できます。これにより、過剰な権限付与やキーの盗難にはるかに簡単に対処できます。共通の特権を共有している多くのユーザーがいる場合、グループを使用することも選択できますが、ユーザーに直接ポリシーを添付しないようにしてください。

3. 多くの特権を与えすぎる

権限を処理する場合、最小限の特権の原則に従って実行してください。1人のユーザーまたは1つのロールがサービスにアクセスする必要がある場合、それらがジョブを実行するために実施する必要のある特定のアクションを収集し、IAMエンティティにそれらの特権を割り当てる必要があります。簡単な方法を選択して、サービス全体へのアクセス権を付与しないようにします。このように、原則はシンプルでも非常に強力な権限セットが多くあるため、誤って付与されると破滅的な結果となる恐れがあります。

4. 未使用の認証情報を保持する

インフラストラクチャ全体でキーや、アクティブなユーザーとロールを常に追跡する必要があります。何らかの理由で、ユーザーが非アクティブになった場合（休暇や休職など）、これらのキーを指定した期間に非アクティブにして、一定期間が経過したら削除することを推奨します。

これにより、権限が付属するキーのセットがまったく残らないため、環境にセキュリティ上の欠陥が発生することはありません。内部からの攻撃にさらされるより、ユーザーを再作成するほうが常に得策です。

2023年版クラウドリスクレポート

この新しいレポートをダウンロードして、2023年に注意すべきクラウドセキュリティのリスクと、2024年に保護を維持するための最善の対処方法を確認してください。

今すぐダウンロード

サマリー

インフラストラクチャの変更により問題が発生することはよくあることです。慎重に実行しないと、データが危険にさらされる可能性があります。このようなリスクは、上記の設定ミスを徐々に意識的に防ぐように変更を加えることで軽減できます。

また、クラウドストライクは必要となるセキュリティを提供することができます。当社は、脅威の検知と修復の区別を実現したことでAWSから高い評価を受けています。CrowdStrike Falcon^® for AWSを使用すると、ここに記載されたすべての問題やその他の問題を分析して軽減できます。