トップ > AWS Well-Architected > セキュアなAWS環境の設計についての解説【2024年版】

セキュアなAWS環境の設計についての解説【2024年版】

AWS Well-Architected セキュリティ
記事タイトルとURLをコピーする

こんにちは！イーゴリです。

AWS にとって、クラウドのセキュリティは最優先事項です。(AWS公式ページ)

AWS環境のセキュリティ対策としてAWSサービスを解説するよりも、まずはAWS環境の最適な設計について考える必要があります。AWS Well-Architected Frameworkを考慮しながらの設計を推奨します。AWS Well-Architected Frameworkを全部詳しく読むことをおすすめしますが、この記事では個人的に一番重要だと思う点について記載します。

とてもざっくり説明しますと、AWS Well-Architected Frameworkとは、クラウドシステムの最適な設計方法を提供するAWSのガイドラインで、6つの柱があります。この記事では基本的に「セキュリティ」の柱を技術的観点から見てみたいと思います。

AWS Well-Architected Frameworkの柱：

  • 運用上の優秀性
  • セキュリティ
  • 信頼性
  • パフォーマンス効率
  • コスト最適化
  • サステナビリティ

下記の注意事項があります。

  • AWS Well-Architected Frameworkの全部の項目に沿っていなければいけないというわけではありません！ベストプラクティスを知った上で、ビジネス的な判断で決めないといけません。例えば、特定のビジネス要件に基づいて、AWS Well-Architected Frameworkの一部の推奨事項を調整する必要がある場合もあります。例えば、予算やリソースの制約から、全てのベストプラクティスを即座に実装することが難しい場合などです。そのようなケースでは、優先順位をつけて実施していくことが重要です。
  • この記事は、基本的にAWS Well-Architected Frameworkの通りの説明になりますが、AWS Security Hubや米国国立標準技術研究所（NIST）のレコメンデーションや個人的な意見もありますので、記載した情報の参考元を項目ごとに記載します。「AWS Well-Architected Framework◯◯ (URL)」や[Security Hub◯◯ (URL)]のように参考元が記載されていない場合は個人的な意見となりますので、ご注意ください。
  • この記事ではAWS Organizationsの設計を割愛します。AWS Organizationsの設計については下記の佐竹さんの記事をご参考ください。 blog.serverworks.co.jp

AWS環境のセキュリティについての解説を３つの記事に分けます。

  • ①セキュアなAWS環境の設計（本記事）
  • ②AWS環境のセキュリティ対策→具体的なAWSサービスの紹介（作成予定）
  • ③AWS環境のセキュアな運用→具体的なAWSサービスの紹介（作成予定）

セキュアなAWS環境の設計

ワークロードの設計

環境 (本番、ステージング、開発、テストなど)ごとにアカウントを分けます。アカウントレベルの分類は、セキュリティ、請求、アクセスのために強力な分離境界を提供するため、強く推奨されます。下記に簡単なイメージ図を作成しました。

イメージ図：

SEC01-BP01 アカウントを使用してワークロードを分ける
省略
このベストプラクティスが確立されていない場合のリスクレベル: 高 docs.aws.amazon.com

Identity and Access Management（IAM）の設計

IAMポリシーはグループ/ロールに付与する

当たり前のことですが、IAMポリシーは、ユーザーではなく、グループやロールに直接アタッチすることをお勧めします。

最小特権のアクセスを付与する

SEC03-BP02 最小特権のアクセスを付与します
省略
このベストプラクティスが確立されていない場合のリスクレベル: 高 docs.aws.amazon.com

例えば、デフォルトでユーザーに管理者アクセス許可を付与するのではなく、必要な権限のみ与えます。あるサービスにFull Accessが必要だとしても管理者アクセス許可ではなく、EC2 Full AccessやRDS Full Accessなどを付与し、他のサービスにアクセスする権限が必要でなければ、余計な権限を付与するのはNGです。

一時的な認証情報を使用する

SEC02-BP02 一時的な認証情報を使用する
省略
このベストプラクティスが確立されていない場合のリスクレベル: 高 docs.aws.amazon.com

例えば、各アカウントでIAMユーザーを作成するのではなく、
①１つのAWS専用アカウント（踏み台アカウント）でユーザーを作成し、スイッチロールで別のアカウントにアクセスします。 blog.serverworks.co.jp イメージ図： ②AWS IAM Identity Center (旧AWS SSO)を使って、複数のAWSアカウントにログインします(AWS Organizationsが必須)。 blog.serverworks.co.jp イメージ図：

なお、なるべくIAM ユーザーのアクセスキーの発行はやめて、IAMロールを使ったほうが安全です。

IAMのアクセスキーを利用する場合、広範な権限が漏洩するリスクは減らせるものの、アクセスキーそのものをGitの公開リポジトリなどにアップロードしてしまい、漏洩する可能性があります。一方、IAMロールを使用すると、プログラムにアクセスキーを埋め込む必要がなくなるため、アクセスキーの漏洩リスクを大幅に減らすことができます。

SEC02-BP02 一時的な認証情報を使用する
一般的なアンチパターン:
開発者が、フェデレーションを使って CLI から一時的な認証情報を取得するのではなく、IAM users からの長期的なアクセスキーを使用する。
開発者がコードに長期的アクセスキーを埋め込んで、そのコードをパブリック Git リポジトリにアップロードする。
docs.aws.amazon.com

ルートユーザーは必要ない限り使わない

SEC01-BP02 セキュアアカウントのルートユーザーおよびプロパティ
省略
このベストプラクティスが確立されていない場合のリスクレベル: 高 docs.aws.amazon.com

例えば、私がAWSアカウントを作り、他のメンバーにIAMユーザーを作って最小特権のアクセスを付与した場合、私が自分でルートユーザーを使って日常業務を行うのはNGです。

ルートユーザーにアクセスキーを作成しない/削除する

AWSのベストプラクティス的にはAWSアカウント用のアクセスキーを作成しないことが推奨されています。ルートユーザーにすでにアクセスキーがある場合、削除することをご検討ください。

ルートユーザーのアクセスキーは作成しないでください
アクセスキーを使用すると、AWS コマンドラインインターフェイス (AWS CLI) でコマンドを実行することや、いずれかの AWS SDK から API オペレーションを使用することができます。ルートユーザーには請求情報を始めとするアカウントのすべての AWS のサービスとリソースへのフルアクセスがあるので、ルートユーザー用のアクセスキーペアを作成しないことを強くお勧めします。 docs.aws.amazon.com

そもそもルートユーザー以外にもベストプラクティスとして、アクセスキーを使用した認証からIAMロールを使用した認証に切り替えることをお勧めします。「一時的な認証情報を使用する」の項目に記載した通りです。IAMのアクセスキーを利用する場合、広範な権限が漏洩するリスクは減らせるものの、アクセスキーそのものをGitの公開リポジトリなどにアップロードしてしまい、漏洩する可能性があります。一方、IAMロールを使用すると、プログラムにアクセスキーを埋め込む必要がなくなるため、アクセスキーの漏洩リスクを大幅に減らすことができます。

SEC02-BP02 一時的な認証情報を使用する
一般的なアンチパターン:
開発者が、フェデレーションを使って CLI から一時的な認証情報を取得するのではなく、IAM users からの長期的なアクセスキーを使用する。
開発者がコードに長期的アクセスキーを埋め込んで、そのコードをパブリック Git リポジトリにアップロードする。
docs.aws.amazon.com

多要素認証 (MFA)を設定/強力なパスワードを設定する

SEC02-BP01 強力なサインインメカニズムを使用する
省略
このベストプラクティスが確立されていない場合のリスクレベル: 高 docs.aws.amazon.com

多要素認証 (MFA)

パスワードだけだとハッキングされやすい時代ですので、多要素認証を設定することが必要です。多要素認証の設定漏れがないように「MFA強制ポリシー」を作って適用すると、ユーザーは自身のアカウントで多要素認証（MFA）を設定しないと何も操作できなくなりますので、有効な方法です。

設定方法は下記の記事にありますので、ご参考ください。

blog.serverworks.co.jp blog.serverworks.co.jp

ちなみに最近、指紋認証も多要素認証として使えるようになりましたので、一時的なパスコードを入力するほかに、指紋認証を設定すると指紋でもログインできます。

※AWS Organizationを使う場合、SCP(サービスコントロールポリシー)でMFA強制ポリシーを適用できます。

強力なパスワード

強力なパスワードポリシーを設定する必要があります。

AWSのパスワードデフォルトのパスワードポリシーは下記となりますが、ポリシー設定の変更については下記の記事をご参考ください。

デフォルトのパスワードポリシーでは、次の条件が適用されます。
パスワードの文字数制限: 8～128 文字
大文字、小文字、数字、英数字以外の文字 (! @ # $ % ^ & * ( ) _ + - = [ ] { } | ') のうち、最低 3 つの文字タイプの組み合わせ
AWS アカウント 名または E メールアドレスと同じでないこと
有効期限のないパスワード

docs.aws.amazon.com

強力なパスワードの作り方
  • パスワードの長さ：14文字以上、大文字、小文字、数字、英数字以外の文字 (! @ # $ % ^ & * ( ) _ + - = [ ] { } | ') のうち、最低 3 つの文字タイプの組み合わせ

使用されているパスワードが緑ゾーンにあるかご確認ください。

https://www.hivesystems.com/password-table

  • 人気のパスワードや辞書にある言葉を組み合わせたパスワードなどの利用は禁止：Pa$$w0rd、Qwerty123!などの超人気のパスワードや、人物名、キャラクター名、製品名、組織名など存在している言葉を使ってしまうと攻撃者がレインボーテーブルを使用し、パスワードをハッキングできる可能性がありますので、注意が必要です。

  • パスワードの再利用は禁止

下記の表はhivesystems.comによる調査結果です。パスワードが辞書にある言葉を使用していた、またはウェブサイト間でパスワードを再利用していた場合のパスワードハッキング時間です。

https://www.hivesystems.com/blog/are-your-passwords-in-the-green

  • パスワードに「有効期限」を設定しない

米国国立標準技術研究所（NIST）は、ユーザーからの要請やセキュリティ侵害の明確な証拠がない場合、定期的なパスワード変更を要求しないよう推奨しています。ユーザーが十分に強力なパスワードを何度も作成するのは困難であるためです。

“Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”

Users tend to choose weaker memorized secrets when they know that they will have to change them in the near future. When those changes do occur, they often select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password. This practice provides a false sense of security if any of the previous secrets has been compromised since attackers can apply these same common transformations. But if there is evidence that the memorized secret has been compromised, such as by a breach of the verifier’s hashed password database or observed fraudulent activity, subscribers should be required to change their memorized secrets. However, this event-based change should occur rarely, so that they are less motivated to choose a weak secret with the knowledge that it will only be used for a limited period of time.

pages.nist.gov

PCI DSS基準に「パスワードは少なくとも90日ごとに変更する」というような文章がありますが、PCI DSSなどの基準に準拠する必要性がない場合、最初の段階で一度複雑性の高いパスワードを設定しておくといいかもしれません。

「こんな難しいパスワードを覚えられる？」と思う方がいらっしゃると思いますが、すべてのパスワードを覚える必要はありません。いろいろなパスワードマネージャーがありますので、パスワードマネージャーへのアクセスだけきちんと管理しておけば、他のパスワードを覚える必要はなくなります。

個人的な意見：パスワードマネージャーなどのパスワードツールを使わないと、使い回さない複雑性の高い複数のパスワードは中々覚えられないと思います。

パスワードマネージャーについてのNISTの意見

In SP 800-63B, NIST has not explicitly recommended the use of password managers, but recommends that verifiers permit the use of “paste” functionality so that the subscriber can use a password manager if desired. pages.nist.gov

IAMユーザーを使い回さない

常識の話だと思いますが、念の為に記載します。 誰が何を行ったか特定できるために、IAMユーザーを使い回してはいけません。

ネットワークレイヤーの設計

パブリックサブネットにある自分で管理するリソースをAWSマネージドサービスに変えられないか検討する

ネットワークの攻撃面を減少させるために下記のような対策が必要だと思いますが、AWS Well-Architected Frameworkに明確に記載されていないため、あくまで個人的な意見となりますが、可能であれば、パブリックサブネットにEC2などのAWSで管理されていないリソースを置かないほうが良いと思いますので、AWSマネージドサービスに変えられないか検討する。

例えば、

①EC2を踏み台として使いたい場合、別の安全な方法がありますので、下記の記事をご参考ください。

②インターネットに公開しているEC2をプライベートサブネットに置いて、代わりにパブリックサブネットにElastic Load Balancerを配置することを検討してください。

インターネットからアクセスする必要がないリソースをプライベートサブネットに配置する

SEC05-BP01の通り不正アクセスによる潜在的な影響範囲を最小化するには、インターネットアクセスを必要としない仮想プライベートクラウド (VPC) 内のデータベースクラスターは、インターネットへのルート、またはインターネットからのルートがないサブネットに配置する必要があります。

SEC05-BP01 ネットワークレイヤーを作成する
省略
このベストプラクティスが確立されていない場合のリスクレベル: 高 docs.aws.amazon.com

イメージ図：

すべてのレイヤーでトラフィックを制御する

SEC05-BP02 すべてのレイヤーでトラフィックを制御する
省略
このベストプラクティスを活用しない場合のリスクレベル: 高 docs.aws.amazon.com

例えば、セキュリティグループの場合、下記のような対策が必要だと思います。

  • デフォルトのセキュリティグループを使わないこと
  • プライベートサブネットでも「すべて許可」というインバウンドルールを使わないこと
  • 使わないポートを閉じること
  • そもそもポートを開放してもよいかよく考慮すること
    ①SMB(TCP 445)などの高リスクのポートを外に開放してはいけません。WannaCryがSMBの脆弱性を使って、サーバーを感染させたという事例もあったので、どうしてもこのようなポートを開放したい場合、VPN等経由で接続してください。
    blog.serverworks.co.jp blog.serverworks.co.jp ②SSH/RDPポートを開放する場合、ソースを0.0.0.0/0にしてはいけません。VPN経由で接続するかもしくはソースを厳しく制限してください。

一部のAWSサービスはインターネット接続が必須で、AWS APIへの呼び出しを行うために公開APIエンドポイントを利用します。一方で、Amazon Virtual Private Cloud（VPC）内部で動作するサービスは、VPCエンドポイントを通じてAWSリソースと安全に通信することが可能です。特に、Amazon S3やAmazon DynamoDBのようなサービスは、VPCエンドポイントのサポートが提供されており、これによりVPC内のリソースからこれらのサービスへの直接アクセスが容易になります。よって、セキュリティを高めると同時に、ネットワークトラフィックの効率も向上します。

イメージ図：

下記の記事をご参考ください。 blog.serverworks.co.jp

AWS PrivateLinkは、AWSサービス、サードパーティのサービス、または他のVPCでホストされる独自のサービスに安全にアクセスするための推奨される方法です。このサービスを使用すると、すべてのネットワークトラフィックがAWSのグローバルバックボーン内に留まり、インターネットを介して外部に流れ出ることはありません。

なお、セキュリティグループやNACLの機能が足りない場合、AWS Network Firewallを検討してください。

セキュリティグループ Network ACL AWS Network Firewall
ユースケース アクセス制御 アクセス制御 トラフィック調査とフィルタリング、侵入防止
タイプ ステートフル ステートレス ステートフル/ステートレス
OSIレイヤー L3-4 L3-4 L3-L7
AWS Firewall Manager 対応 未対応 対応
ルール数のクォータ ※1 60個 (最大1000まで緩和可能) 20個（最大40個まで緩和可能だが、パフォーマンスに影響する可能性あり） 3万個 (ステートフルルールの場合：最大5万個まで緩和可能だが、パフォーマンスに影響する可能性あり)
課金 なし なし あり

※1 クォータについては最新情報をご参照ください。

下記の日高さんの記事もご参考ください。

blog.serverworks.co.jp

セキュリティグループ内の高リスクのポートを閉じる

上記に書いた通り、セキュリティグループ内のリスクの高いポートへの無制限アクセスを許可しないでください。

Security Hub：[EC2.19] セキュリティグループは、リスクの高いポートへの無制限アクセスを許可してはいけません docs.aws.amazon.com

  • 20、21 (FTP)
  • 22 (SSH)
  • 23 (Telnet)
  • 25 (SMTP)
  • 110 (POP3)
  • 135 (RPC)
  • 143 (IMAP)
  • 445 (CIFS)
  • 1433、1434 (MSSQL)
  • 3000 (Go、Node.js、および Ruby のウェブ開発フレームワーク)
  • 3306 (mySQL)
  • 3389 (RDP)
  • 4333 (ahsp)
  • 5000 (Python ウェブ開発フレームワーク)
  • 5432 (postgresql)
  • 5500 (fcp-addr-srvr1)
  • 5601 (OpenSearch ダッシュボード）
  • 8080 (proxy)
  • 8088 (レガシー HTTP ポート)
  • 8888 (代替 HTTP ポート)
  • 9200 または 9300 (OpenSearch)

デフォルトのセキュリティグループのすべてのルールの削除

AWS Well-Architected Frameworkではなく、Security Hubの項目になりますが、下記のAWS Security HubのEC2.2項目の通り、VPC のデフォルトのセキュリティグループではインバウンドトラフィックまたはアウトバウンドトラフィックは削除したほうが良いです。

[EC2.2] VPC のデフォルトのセキュリティグループでは、インバウンドトラフィックまたはアウトバウンドトラフィックを許可しないようにすることをお勧めします docs.aws.amazon.com

アタッチされていないセキュリティグループの削除

AWS Security HubのAWS Foundational Security Best Practices 標準および NIST SP 800-53 Rev. 5 から削除された項目ですが、個人的には重要な項目だと思いますので、紹介します。意図のあるケースではない限り、アタッチされていない（使われていない）セキュリティグループを削除してください。特に「launch-wizard-XX」のセキュリティグループを削除することが重要です。間違ってアタッチしてしまうと、大事故に繋がる可能性がありますので、ご注意ください。

[EC2.22] 未使用の Amazon EC2 セキュリティグループを削除することをお勧めします

特定の標準から廃止 – Security Hub は、2023 年 9 月 20 日に AWS Foundational Security Best Practices 標準および NIST SP 800-53 Rev. 5 からこのコントロールを削除しました。このコントロールは、引き続きサービスマネージドスタンダード: の一部です AWS Control Tower。この コントロールでは、セキュリティグループが EC2 インスタンス、または Elastic Network Interface にアタッチされている場合に、合格の検出結果を生成します。ただし、特定のユースケースでは、セキュリティグループがアタッチされていなくてもセキュリティ上のリスクはありません。他の EC2 コントロール (EC2.2、EC2.13、EC2.14、EC2.18、EC2.19 など) を使用すると、セキュリティグループをモニタリングできます。 docs.aws.amazon.com

デフォルトVPCの削除

各リージョンごとにデフォルトのVPCが1つありますので、ネットワークの攻撃面を減少させるために、デフォルトVPCは削除したほうがよいと個人的には思います。

暗号化

保管中のデータの暗号化

保管中データの暗号化の必要性について下記の記事に記載しましたが、今回はAWS Well-Architected Frameworkの通り設計することが目的なので、データの暗号化を行います。下記の記事でKMSの使用についても説明しましたので、こちらでは割愛させてください。

blog.serverworks.co.jp

SEC08-BP02 保管中に暗号化を適用する

データを保存する唯一の方法は、暗号化を使用することだということを確実にする必要があります。AWS Key Management Service (AWS KMS) は、保管中のすべてのデータをより簡単に暗号化できるように、多数の AWS のサービスとシームレスに統合します。
省略
このベストプラクティスを活用しない場合のリスクレベル: 高

  • S3：2023 年 1 月 5 日以降、Amazon S3 にアップロードされるすべての新しいオブジェクトは、追加費用なしで、パフォーマンスに影響を与えずに自動的に暗号化されます。 docs.aws.amazon.com
  • EBS：新しい Amazon EBS ボリュームのデフォルトの暗号化を設定する: 新しく作成したすべての Amazon EBS ボリュームを暗号化形式で作成することを指定します。AWS が提供するデフォルトキーを使用するか、作成したキーを使用するかを選択できます。 blog.serverworks.co.jp
  • RDS：RDSの暗号化を設定する

各サービスの暗号化についてセキュリティガイドをご参考ください。

伝送中のデータの暗号化

パブリック向けリソースとの間で暗号化されているトラフィックのみ許可する必要があります。 例えば、Webの場合、HTTP(80ポート)ではなく、HTTPS(443ポート)を使いましょう。古い/廃止されたバージョンの SSL/TLSは使わないでください。

SEC09-BP02 伝送中に暗号化を適用する
省略
このベストプラクティスを活用しない場合のリスクレベル: 高 docs.aws.amazon.com

  • ELB、S3など：上記に書いた通り、HTTPS(443ポート)を使用する。HTTPS (TLS) を使用すると、潜在的な攻撃者が中間者攻撃または同様の攻撃を使用してネットワークトラフィックを盗聴または操作することを防止できます。
  • EBS：ボリュームを暗号化するとEC2ーEBS間の通信も暗号化されます。
  • RDS：デフォルトで認証機関が設定されています。なお、選択肢から別のサーバー証明書を選ぶことができます。

ログの収集

必要に応じて各サービスごとにログを収集します。

サービスとアプリケーションのログ記録を設定することは重要ですが、各サービスのログの何を収集できる/できないかを事前に把握することはもっとも重要です。

例えば、AWS Client VPNのログ収集をオンにして、誰がアクセスできたか/できなかったか（トラブルシューティングや不正アクセス調査など）のためにログを収集する予定があって、ログを収集したとします。収集したログを見るとクライアント VPN エンドポイントの認証失敗の数はありますが、失敗ログの詳細はありませんので、ご注意ください。

ログに関してもっともやってはいけない注意点：

  • ①ログが誰でも見られる状態にしておくこと
  • ②ログを永久保存、またはすぐに削除される設定にしておくこと
  • ③ログを目的なしで収集すること

上記の場合、意味のないログを集めてしまい、意味のない課金(Cloudwatch/S3料金など)が発生します。ログを集めてこのログで何をするかという定義（例：不正アクセス調査のため、◯◯のトラブルシューティングのためなど）が必要だと思います。

一般的なアンチパターンについては下記（SEC04-BP01）の項目を御覧ください。

SEC04-BP01 サービスとアプリケーションのログ記録を設定する
省略
このベストプラクティスが確立されていない場合のリスクレベル: 高
docs.aws.amazon.com

ちなみに、弊社がサバソック（マネージドセキュリティサービス）というサービスを開始したので、興味がありましたら、是非ご検討ください。

以上、御一読ありがとうございました。

本田 イーゴリ (記事一覧)

カスタマーサクセス部

・2024 Japan AWS Top Engineers (Security)
・AWS SAP, DOP, SCS, DBS, SAA, DVA, CLF
・Azure AZ-900
・EC-Council CCSE

趣味：日本国内旅行(47都道府県制覇)・ドライブ・音楽