セキュリティの要点

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 CLI を設定する (AWS シングルサインオンの後継記事) 」の記事を参照してください。

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

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

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

AWS でリソースを作成する際には、使用するリソースの種類に応じて推奨されるセキュリティのベストプラクティスに従うように注意する必要があります。EC2 インスタンスの場合、セキュリティは VPC やセキュリティグループを設定するなどして、インスタンスへのネットワークアクセスを制御することから始まります。(詳細については、「構築するインフラストラクチャの保護」セクションの「Amazon VPC セキュリティ」を参照してください)。

インスタンスのセキュリティのもう 1 つの側面は、インスタンスへの接続に使用される認証情報の管理です。これは、割り当てた IAM ユーザー許可から始まりますが、割り当てられたグループにも及びます。これにより、EC2 インスタンスを使用するユーザーにはある程度のセキュリティがもたらされますが、インスタンス自体にはもたらされません。また、インスタンスにアタッチされている IAM ロールと、それらのロールに関連する権限を設定する必要があります。EC2 インスタンスにアクセスするには、 SSH 用のポートを開いたり、要塞/ジャンプホストを設定したりする代わりに、 EC2 Instance Connect を使用する必要があります。

インスタンスにデプロイされたゲストオペレーティングシステムとソフトウェアが、オペレーティングシステムの更新やセキュリティパッチを適用して最新の状態であることを確認する必要があります。 詳細については、 Amazon EC2 のセキュリティをご覧ください。

データベースを保護することは、セキュリティアプローチの重要な側面です。Amazon VPC セキュリティセクションで説明したように、インターネット経由で外部からのアクセスを防ぐために、データベースをプライベートサブネットにデプロイすることをお勧めします。AWS では 15 の目的別データベースを提供しています。セキュリティはそれぞれ異なりますが、すべてに次の共通点があります。

データベースにアクセスするには、何らかの認証が必要です。これはユーザー名とパスワードの形式をとることができますが、これらは定期的に変更する必要があります。別の方法として、 Amazon RDS Proxy を使用して IAM ロールを利用してデータベースへのアクセスを管理することもできます。Amazon DynamoDB などの一部のデータベースサービスでは、 IAM ロールを使用してアクセスを提供するため、認証情報を自分で管理する必要はありません。

SSH は EC2 インスタンスを管理する最も一般的な方法の 1 つです。Amazon EC2 Instance Connect では、SSH を使用してコンソールで直接 1 回限りの SSH キーを使って EC2 インスタンスに接続できます。以下の記事では、 Amazon EC2 Instance Connect を有効にする方法の概要を示し、一般的なユースケースについて説明します。EC2 インスタンスを作成するときに SSH キーを生成し、ローカルにダウンロードし、それを使用してインスタンスに接続することもできます。ただし、そのためには、これらのキーを保護し、アクセスできなくなることのない場所に保管し、それらのキーをダウンロードしたマシンからのみインスタンスに接続できるようにする必要があります。EC2 Instance Connect は、コンソールから、マシン間で、使いやすい方法で同じ SSH へ安全にアクセスできるようにします。

データベースへのアクセスを、アクセスを必要とするサービスとインフラストラクチャのみに制限することが、推奨されるベストプラクティスです。これは、RDS インスタンス、 Amazon Neptune データベース、または Amazon Redshift クラスターのセキュリティグループを設定することで実行できます。

バックアップと復元のテスト

データをバックアップし、頻繁に復元を実行して、バックアップが正しく機能していることを優先的に確認する必要があります。AWS バックアップを使用すると、Amazon RDS、DynamoDB、Neptune など特定の AWS サービスのバックアップを簡単に設定および管理できます。

サーバーレスセキュリティについては、 AWS Lambda 、 Amazon API Gateway、Amazon DynamoDB、 Amazon SQS 、および IAM に精通している必要があります。サーバーレスセキュリティでは、責任分担モデルと比較して AWS の責任は大きくなりますが、それでも知っておくべきお客様の責任があります。サーバーレス環境では、AWS がインフラストラクチャ、コンピューティング、実行環境、およびランタイム言語を管理します。図に示すように、顧客は顧客機能コードとライブラリ、リソース構成、IDとアクセス管理を担当します。

以下のセクションでは、お客様の責任となるセキュリティ慣行について詳しく説明します。詳細については、「AWS Lambda のセキュリティ」を参照してください。

AWS Lambda には、Amazon Linux ベースの実行環境で関数コードを実行するランタイムが用意されています。ただし、関数に追加のライブラリを使用する場合は、ライブラリを更新するのはお客様の責任です。ライブラリを最新の状態に保つことは、セキュリティ体制を維持するのに役立ちます。

AWS Lambda は、Amazon DynamoDB、Amazon EventBridge、Amazon Simple Notification Service (Amazon SNS) など、複数の AWS リソースと統合されています。関数の一部として使用する各サービスに推奨されるセキュリティプラクティスに従うことは、セキュリティ体制を強化するのに役立ちます。各サービスのドキュメントには、追加のガイダンスが記載されています。

Lambda 関数を実行するには、特定の IAM 許可とロールが必要になる場合があります。詳細については、『AWS Lambda 開発者ガイド』の「アクセス許可」セクションを参照してください。

セキュリティ戦略には、監視、ロギング、および構成管理も含める必要があります。例えば、多くの組織では、TACACS+ プロトコル、RADIUS、または Active Directory ログを使用してデバイスのアカウンティングを有効にしています。これにより、すべての管理アクティビティについて確実に監査証跡が作成されるようになります。AWS クラウド内では、AWS CloudTrail を使用してこれを行うことができます。CloudTrail は、ユーザーのアクティビティや API の使用状況を追跡することで、監査、セキュリティモニタリング、運用トラブルシューティングを可能にします。AWS Serverless Application Repository は、デベロッパーや企業が AWS クラウドでサーバーレスアプリケーションをすばやく検索、デプロイ、公開できるようにするもので、AWS CloudTrail と統合されています。詳細については、 AWS サーバーレスアプリケーションリポジトリ開発者ガイドを参照してください。

それでも、サーバーレス環境にはある程度の DoS とインフラストラクチャ保護を提供する必要があります。これは AWS Shield と AWS Shield Advanced で行うことができます。脅威の監視と検出については、「環境の監視」セクションで詳しく説明しています。

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 クライアント 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 環境内で自動修復アクションを開始させることもできます。

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