セキュリティの要点

セキュリティとコンプライアンスは AWS とお客様の間における責任共有です。この共有モデルに従えば、「クラウドの」コンポーネントの運用、管理、制御は AWS が責任を持つため、お客様は運用上の負担を軽減できます。 そのため、お客様はアプリケーションの構築とサービスの実装に集中する一方で、それらのサービスを「クラウドで」保護する責任を引き受けることになります。 責任共有モデルの詳細をご覧ください。

AWS アカウントを作成するときは、ルートユーザーと呼ばれるユーザーから始めます。これは AWS アカウント内に存在する最初の AWS ユーザーです。AWS は、このアカウントを日常の運用には使用しないことをお勧めします。アカウントへの完全なアクセスと制御が行え、推奨されるベストプラクティスに従ってルートユーザーを保護する必要があるためです。これには、ルートユーザーのアクセスキーをロックすること、強力なパスワードを使用すること、AWS 多要素認証を有効にすること、アカウントにアクセスするための IAM ユーザーを作成することが含まれます。このアカウントには管理者権限を割り当てることができ、今後のすべての管理タスクに使用する必要があります。

次に、アカウントに代替セキュリティ連絡先を割り当てる必要があります。代替セキュリティ連絡先は、AWS Trust & Safety チームからの通知を含むセキュリティ関連の通知を受け取ります。アカウント設定の早い段階でこの連絡先情報を設定することの重要性について詳しくは、ブログ記事「AWS アカウント全体の代替セキュリティ連絡先を更新して、セキュリティ通知をタイムリーに受け取る」を参照してください。

セキュリティ連絡先を確認したら、ワークロードを実行すべき AWS リージョンと実行しないリージョンを検討する必要があります。その後、未使用のリージョンをロックダウンして、それらのリージョンからワークロードを実行できないようにすることができます。これはコストの最適化に役立ちますが、セキュリティにも役立ちます。具体的にどういうことでしょうか? ワークロードを実行する予定のないリージョンをロックダウンすることで、積極的に使用するリージョンに監視作業を集中できます。

この時点で、ルートユーザーを保護し、1 人以上の IAM ユーザーを作成し、セキュリティ連絡先を割り当て、ワークロードを実行できるリージョンをロックダウンしました。次に、ユーザーが AWS リソースとどのようにやり取りするかを考えてみましょう。操作には、AWS CLI と AWS マネジメントコンソールという主に 2 つの方法があります。AWS CLI とコンソールにシングルサインオンを設定することをお勧めします。AWS IAM アイデンティティセンターを使用してアクセスを一元管理する方法の詳細については、「AWS IAM アイデンティティセンター (AWS Single Sign-On の後継) を使用するように AWS CLI を設定する」の記事を参照してください。

アカウントを保護する次のステップは、アクセスを制御する AWS IAM ユーザーグループを設定することです。ユーザーに直接ポリシーを設定して個々のユーザーのアクセスを制御するよりも、グループを作成して必要な許可を割り当て、そのグループにユーザーを割り当てるのが最適です。ユーザーはそのグループの許可を継承します。これにより、よりスケーラブルな方法で多くのユーザーにアクセス制御を行うことができます。IAM と IAM グループは複数のサービスにまたがっているため、理解しておくことが重要です。IAM は、すべての AWS のサービスと一定程度相互作用するサービスなので、時間をかけて IAM に慣れるようにしましょう。

最初からこのようなプラクティスに従うことで、AWS リソースに安全にアクセスするのに役立ちます。次は、AWS で構築するインフラストラクチャを保護する方法について説明します。

構築するインフラストラクチャは、基盤となるアーキテクチャの一部であり、顧客向けのものではないため、見過ごされがちです。ただし、インフラストラクチャに障害が発生すると、顧客に提供するサービスも機能しなくなります。このため、インフラストラクチャを初めから保護することが非常に重要です。

クラウドインフラストラクチャを構築する際には、まず Amazon Virtual Private Cloud (Amazon VPC) を作成します。これはユーザーが定義した仮想ネットワークで (デフォルトはアカウントの作成時に各リージョンに作成されます)、リソースを起動できます。VPC は、CIDR IP アドレス範囲が割り当てられ、サブネットを作成することによって細分化されるという点で、従来のネットワークに似ています。サブネットを使用して、さまざまなリソースセットを分離できます。サブネットはパブリックとプライベートのどちらでも可能です。パブリックサブネットにはインターネットゲートウェイへのルートがあり、このゲートウェイを経由してインターネットにアクセスでき、関連するアクセス制御で許可されていればインターネットからアクセスすることもできます。プライベートサブネットにもルーティングテーブルがありますが、インターネットゲートウェイへのルートがないため、デフォルトではインターネットにアクセスできず、インターネットからアクセスすることもできません。プライベートサブネット内のリソースがインターネットにアクセスできるようにするには、NAT ゲートウェイが必要です。サブネットレベルでは、ネットワークアクセスコントロールリスト (ACL) が特定のインバウンドまたはアウトバウンドトラフィックを許可または拒否します。VPC にはデフォルトのネットワーク ACL を使用することも、VPC 用のカスタムネットワーク ACL を作成することもできます。ネットワーク ACL は番号付きのリストで、上から順に処理され、ステートレスです。つまり、双方向のトラフィックを許可するには、インバウンドとアウトバウンドのネットワーク ACL ルールが必要になります。

EC2 リソースを VPC にデプロイするときに、セキュリティグループをそれらに関連付けます。セキュリティグループは、EC2 リソースに到達できるインバウンドトラフィックとアウトバウンドトラフィックを制御します。セキュリティグループはファイアウォールに似ていますが、IP アドレスのリストや範囲だけを使用する代わりに、リソース参照と呼ばれるものを指すこともできます。リソース参照とは、グループ内の各リソースに割り当てられた IP アドレスの最新リストを管理する名前付きのグループです。例えば、Amazon EC2 インスタンスを起動する自動スケーリンググループを作成すると、起動時に各インスタンスに新しい IP が割り当てられます。これらのインスタンスにセキュリティグループを追加すると、EC2 インスタンスのセキュリティグループ ID を使用してデータベースサーバーのセキュリティグループへのアクセスを許可できます。また起動された新しい EC2 インスタンスは、その IP アドレスを許可リストに追加しなくてもデータベースにアクセスできます。

セキュリティグループのルールはネットワーク ACL に似ています。作成時にポート、プロトコル、アドレスは一致しますが、ステートフルであり、ステートフルファイアウォールに似ていると考えることができるからです。特定のタイプのトラフィックを許可するエントリを作成する場合、リターントラフィックと一致するルールを作成する必要はありません。ステートフルであれば、リターントラフィックも許可されます。セキュリティグループと ACL がどのように相互作用するかをよりよく理解するには、こちらの比較が役立ちます。

インフラストラクチャのセキュリティをさらに強化するには、AWS Network Firewall をデプロイできます。 ネットワークファイアウォールは、Amazon VPC を保護するマネージドサービスです。接続の追跡やプロトコルの識別などのトラフィックフローからコンテキストを組み込んで、VPC が不正なプロトコルを使用してドメインにアクセスするのを防ぐなどのポリシーを適用できるため、セキュリティグループよりもきめ細かな保護が可能になります。これは、カスタムの Suricata ルールを設定することによって行われます。 例えば、マルウェア攻撃から保護するようにネットワークファイアウォールを設定できます。 これをさらに一歩進めて、DDoS の脅威から保護するために、AWS Shield Advanced という別のマネージドサービスをデプロイできます。

お客様は大量のデータを AWS クラウドに保存します。このデータには、組織の運営に不可欠な情報が含まれています。これには、顧客データ、知的財産、収益に直接関連する注文などが含まれます。このセクションでは、AWS に保存されるデータと、ネットワーク経由で AWS との間で転送されるデータの設定方法に関する基本事項について説明します。

AWS では、データは Amazon S3 に保存されます。Amazon S3 には、データを保護するための複数のコントロールがあります。「Amazon S3 でデータを保護するためのセキュリティベストプラクティス上位 10 選」の記事では、最も基本的なテクニックについて説明しています。これには、組織レベルでパブリック S3 バケットをブロックすること、バケットポリシーを使用して付与されたすべてのアクセスに制限がかけられ特定されていることを確認すること、データを暗号化して保護することが含まれます。

暗号化については、AWS Key Management Service (AWS KMS) を使用して、データの暗号化またはデジタル署名に使用するキーを作成および制御できます。AWS でデータを暗号化したい場合、いくつかのオプションがあります。1 つ目は、Amazon S3 が管理する暗号化キー (SSE-S3) によるサーバー側の暗号化を使用することです。 この方法を使用すると、AWS が管理するキーを使用してデータが AWS に送信された後に暗号化が行われます。

2 つ目の方法は、データが AWS に保存されたら暗号化することですが、AWS で作成および管理されているキーを使用する代わりに、AWS KMS (SSE-KMS) に保存されているカスタマーマスターキー (CMK) を使用してサーバー側の暗号化を実行できます。

暗号化されたデータを AWS に保存する 3 番目のオプションは、クライアント側の暗号化を使用することです。この方法では、データは AWS に転送される前に暗号化されます。

クライアント側の暗号化とサーバー側の暗号化の両方がお客様にどのようなメリットをもたらすかを示す例を次の図に示します。

VPN には複数のテクノロジーが含まれ得ます。VPN の背後にある考え方は、転送中のデータの完全性を維持し、2 者間で安全に交換できるということです。AWS は、転送中のデータを安全に保つのに役立つ複数のテクノロジーを提供しています。その 1 つが AWS PrivateLink です 。これにより、VPC、AWS のサービス、およびオンプレミスネットワーク間で暗号化されたプライベート接続を行えます。これは、トラフィックを公共のインターネットにさらすことなく行われます。これも仮想プライベートネットワークと見なすことができます。

ただし、ほとんどの場合、VPN が話題となるのはデータ暗号化を使用する場面です。状況によっては、クライアントと AWS クラウドリソース間の暗号化が必要になる場合があります。この状況では、AWS Client VPN が必要になります。 一方、データセンターや支店と AWS リソースの間でデータを渡している場合もあるかもしれません。これは、オンプレミスリソースと Amazon VPC または AWS Transit Gateway との間の IPsec トンネルを使用して実現できます。この安全な接続は、サイト間 VPN と呼ばれます。

最後に、AWS マネジメントコンソールを使用してクラウドリソースを管理すると、転送中のデータが暗号化されます。通常、コンソールとの接続を VPN とは呼びませんが、セッションでは TLS (Transport Layer Security) 暗号化が使用されます。そのため、安全なアーキテクチャを構築する際、設定は機密に保たれます。TLS は AWS API でも使用されます。

AWS では、セルフサービスオプションとともに、環境のモニタリングを支援する複数のマネージドサービスを提供しています。例えば、VPC フローログを使用してネットワークトラフィックフローをログに記録して表示したり、Amazon CloudWatch を使用して AWS WAF ログを分析したり、EC2 インスタンスのアラームを作成したりすることができます。 Amazon CloudWatch の詳細については、こちらのワークショップをご覧ください。

さらに、AWS CloudTrail は、AWS インフラストラクチャ全体のアカウントアクティビティをモニタリングして記録し、ストレージ、分析、および修復アクションをコントロールできます。これは、管理監査証跡の作成、セキュリティインシデントの特定、および運用上の問題のトラブルシューティングに不可欠です。

最後に、Amazon GuardDuty は脅威の検出に使用でき、さらに一歩進んで、公開された調査結果から AWS 環境内で自動修復アクションを開始することもできます。

これらの各運用分野に取り組むことで、クラウド環境に不可欠なセキュリティ機能を確立する準備が整います。