asken における AWS アカウント、ユー ザー管理設計

自己紹介 resource "human" "kazuki_numazawa" { name = "沼沢 一樹" company = "株式会社 asken" role = "Infrastructure Engineer" description = <

背景
 3

■ asken では以前から複数の AWS アカウントを利用 ■ AWS アカウントはそれぞれの担当エンジニアが個別に管理 ■ 詳細は語れないが、マルチアカウント運用や専任不在な状態での「あ るある」な課題が山積していた ✔ お察しの良い皆さんは、本日の内容から妄想してください 背景

さてどうしよう

そうだ！ Organizations を 導入しよう！

■ 話すこと ✔ asken での Organizations の設計 ✔ 適用しているガードレール、セキュリティ系サービスの話 ✔ ユーザー、アクセス管理 ■ 話さないこと ✔ Organizations や Control Tower 等、AWS の各サービス自体の 詳細な説明や関連した用語の解説 今日話すこと

AWS アカウント管理
 8

まずやったこと ■ Organizations の管理アカウントとなる AWS アカウントを新規発行 ■ 管理アカウントで作業するための最低限の設定 ✔ root ユーザーに MFA 設定 ✔ Admin 権限 IAM ユーザー発行、ログイン後 MFA 設定 AWS アカウント管理

で、次に何すりゃ ええのん？ AWS アカウント管理

■ Organizations を設計したことがない ■ SCP 設計難しそう ■ ガッツリ詳細に設計しても、今の人数では運用厳しそう AWS アカウント管理

何やら Control Tower というものが あるらしい AWS アカウント管理

AWS アカウント管理

AWS アカウント管理

AWS Control Tower は、ランディングゾーンと呼ばれる安全なマルチアカウント AWS 環境をセットアップおよび管理する ための最も簡単な方法を提供します。 
 AWS Organizations を使用してランディングゾーンを作成し、継続的なアカウント管理とガバナンス、およびクラウドに移 行する数千のお客様と連携してきた AWS の経験に基づいた実装のベストプラクティスを提供 します。
 構築担当者は新しい AWS アカウントを数クリックだけでプロビジョンでき、しかもアカウントは貴社のポリシーに準拠して いるという安心感が得られます。 https://aws.amazon.com/jp/controltower/ より引用 AWS アカウント管理 Control Tower

これだ！ Control Tower を 使ってみよう！ AWS アカウント管理

なんとなく方向性が見えてきたところで Organizations 設計の基本方針を策定 AWS アカウント管理

エンジニアを信頼して権限を最大限渡しつつ守るとこだけきっちり守るスタイル AWS アカウント管理 基本方針 ■ SCP で細かく制御することも可能だが… ■ 厳しく制限しすぎると開発スピードの低下や運用コストが高くなると考えたた め

設計時に参考にした情報 AWS アカウント管理 ■ AWS Organizations における組織単位のベストプラクティス | Amazon Web Services ブログ ■ AWS Organizations と AWS Control Tower を使ったマルチアカウント管理 | Amazon Web Services ブログ

OU 設計 AWS アカウント管理

No content

No content

AWS アカウント管理 - OU 設計 Foundational OU ■ Control Tower によって作成される OU ■ 監査用アカウント、ログ集約用アカウントが稼働 ✔ この2つのアカウントも Control Tower が作成、設定するもの

No content

AWS アカウント管理 - OU 設計 Workload OU ■ ソフトウェアライフサイクルに関連する AWS アカウント用 OU ■ 子 OU として Corporate、Production、SDLC を用意 ✔ 管理をしやすくするため↑の単位で OU を分離

No content

AWS アカウント管理 - OU 設計 Corporate OU ■ 社内システム用 OU Production OU ■ 本番環境用 OU

No content

AWS アカウント管理 - OU 設計 SDLC OU ■ 本番環境ではないアカウントのための OU ■ ステージング環境、開発環境のアカウントを所属させる ■ SDLC は Software Development Life Cycle の略称

No content

AWS アカウント管理 - OU 設計 Suspended OU ■ クローズ予定の AWS アカウント置き場 ■ 不要になったアカウントはここへ移動し、一定期間経過後に削除 ■ ここに配置した AWS アカウントは Control Tower と一部の権限以外は操 作できないようにする SCP を別途付与

No content

AWS アカウント管理 - OU 設計 PolicyStaging OU ■ SCP の変更を検証するための OU ■ ここで検証し、問題ないと判断してから適用することで、設定ミスによる事故 を防ぐことを目的としている

AWS アカウント管理 - OU 設計 AWS Organizations における組織単位のベストプラクティス には 他にも様々な OU があるが、今の asken に必要そうなものだけに絞りました。 将来的には Sandbox OU 等の導入も検討したいところです。 その他の OU は追々検討

各 OU のガードレール AWS アカウント管理

AWS アカウント管理 - 各 OU のガードレール Control Tower から提供されるガイダンスには3つのカテゴリがある ■ 必須のガードレール ✔ 強制的に適用されるもの ■ 強く推奨されるガードレール ✔ マルチアカウント運用のベストプラクティスを適用するように設計されたガードレール ■ 選択的ガードレール ✔ AWS エンタープライズ環境で一般的に制限されている制限事項

AWS アカウント管理 - 各 OU のガードレール このうち「必須のガードレール」には Config / CloudTrail の有効化や Control Tower 関連のリソースに対する操作禁止のルールなどがあり、 Control Tower 管理化になったアカウントに強制的に適用されます。 全ては紹介できないので、詳細は以下をご参照ください。 必須のガードレール - AWS Control Tower

AWS アカウント管理 - 各 OU のガードレール ここでは、「強く推奨されるガードレール」「選択的ガードレール」の うち、各 OU で有効化しているガードレールを「予防」と「発見」に 分けて紹介します。 なお、親子関係にある OU では、親 OU で設定されている ガードレールは子 OU でも有効となります。

No content

No content

■ 予防的ガードレール ✔ ルートユーザーのアクセスキーの作成を許可しない ■ 発見的ガードレール ✔ ルートユーザーの MFA が有効になっているかどうかを検出する ✔ Amazon S3 バケットへのパブリック読み取りアクセスが許可されているかどうかを検出する ✔ Amazon S3 バケットへのパブリック書き込みアクセスが許可されているかどうかを検出する AWS アカウント管理 - 各 OU のガードレール Foundational OU

No content

■ 予防的ガードレール ✔ ルートユーザーのアクセスキーの作成を許可しない ■ 発見的ガードレール ✔ Amazon RDS データベースインスタンスへのパブリックアクセスが有効になっているかどうかを検出する ✔ Amazon RDS データベーススナップショットへのパブリックアクセスが有効になっているかどうかを検出する AWS アカウント管理 - 各 OU のガードレール Workload OU

■ 発見的ガードレール ✔ 無制限の着信 TCP トラフィックが許可されているかどうかを検出する ✔ SSH を介した無制限のインターネット接続が許可されているかどうかを検出する ✔ ルートユーザーの MFA が有効になっているかどうかを検出する ✔ Amazon S3 バケットへのパブリック読み取りアクセスが許可されているかどうかを検出する ✔ Amazon S3 バケットへのパブリック書き込みアクセスが許可されているかどうかを検出する AWS アカウント管理 - 各 OU のガードレール Workload OU

No content

■ 発見的ガードレール ✔ Amazon EC2 インスタンスの Amazon EBS 最適化が有効になっているかどうかを検出する ✔ Amazon EBS ボリュームが Amazon EC2 インスタンスにアタッチされているかどうかを検出する ✔ Amazon EC2 インスタンスにアタッチされた Amazon EBS ボリュームの暗号化が有効になっているかどうかを検出する ✔ Amazon RDS データベースインスタンスのストレージ暗号化が有効になっているかどうかを検出する AWS アカウント管理 - 各 OU のガードレール Production OU

No content

AWS アカウント管理 - 各 OU のガードレール ■ 予防的ガードレール ✔ ルートユーザーのアクセスキーの作成を許可しない ■ 発見的ガードレール ✔ ルートユーザーの MFA が有効になっているかどうかを検出する Suspended OU、PolicyStaging OU

AWS アカウント管理 - 各 OU のガードレール OU 予防的ガードレール 発見的ガードレール Foundational OU ・ルートユーザーのアクセスキーの作成を許可しない ・ルートユーザーの MFA が有効になっているかどうかを検出する ・Amazon S3 バケットへのパブリック読み取りアクセスが許可されているかどうかを検出する ・Amazon S3 バケットへのパブリック書き込みアクセスが許可されているかどうかを検出する Workload OU ・ルートユーザーのアクセスキーの作成を許可しない ・ルートユーザーの MFA が有効になっているかどうかを検出する ・Amazon RDS データベースインスタンスへのパブリックアクセスが有効になっているかどうかを検出する ・Amazon RDS データベーススナップショットへのパブリックアクセスが有効になっているかどうかを検出する ・無制限の着信 TCP トラフィックが許可されているかどうかを検出する ・SSH を介した無制限のインターネット接続が許可されているかどうかを検出する ・Amazon S3 バケットへのパブリック読み取りアクセスが許可されているかどうかを検出する ・Amazon S3 バケットへのパブリック書き込みアクセスが許可されているかどうかを検出する Production OU (Workload OU の子) ・Amazon EC2 インスタンスの Amazon EBS 最適化が有効になっているかどうかを検出する ・Amazon EBS ボリュームが Amazon EC2 インスタンスにアタッチされているかどうかを検出する ・Amazon EC2 インスタンスにアタッチされた Amazon EBS ボリュームの暗号化が有効になっているかどうかを検出する ・Amazon RDS データベースインスタンスのストレージ暗号化が有効になっているかどうかを検出する SDLC OU (Workload OU の子) Corporate OU (Workload OU の子) Suspended OU ・ルートユーザーのアクセスキーの作成を許可しない ・ルートユーザーの MFA が有効になっているかどうかを検出する PolicyStaging OU ・ルートユーザーのアクセスキーの作成を許可しない ・ルートユーザーの MFA が有効になっているかどうかを検出する

■ ガードレールによって最低限の予防とチェックはできるようになった ■ 良かった良かった、めでたしめでたし AWS アカウント管理

ではない

AWS セキュリティ系サービス導入
 52

■ AWS セキュリティ系サービスを導入 ✔ Organizations と統合することで全アカウントへ自動的に適用 ✔ セキュリティとガバナンスの向上を図る AWS アカウント管理 - セキュリティ系サービス できることはまだある

■ Config と CloudTrail は Control Tower によって有効化されている ■ ここにさらに、全 アカウントで GuardDuty, Security Hub, Detective も有効化 ■ Security Hub で検知した内容は Slack に通知 AWS アカウント管理 - セキュリティ系サービス

AWS アカウント管理 - セキュリティ系サービス

AWS アカウント管理 - セキュリティ系サービス ■ GuardDuty, Config, Security Hub, Detective は Audit アカウントに管理を委任 ✔ これによって 監査系のオペレーションを Audit アカウント上でのみ行えるように ● 必要な人にだけ Audit アカウントに対して必要な権限を与えることができる ● Organizations 管理アカウントへのアクセスを増やさずに済む ● 管理アカウントには Organizations を管理する人と請求を確認する人だけにアクセスさせる

No content

ユーザー、アクセス管理
 58

ユーザー、アクセス管理 - Before ■ 誰がどのアカウントにあるのかわかりづらい ■ 利用していないユーザーが残っている ■ MFA 設定が強制できていない ■ 都度ログイン↔ログアウトを繰り返すのが面倒 ■ ユーザー管理の運用が無い (棚卸等) アカウントごとに IAM ユーザーが散在

ユーザー、アクセス管理 - AWS SSO 導入 ■ Organizations の導入を機に、AWS SSO(※) によるログインに移行 ■ 以前から会社で利用していた OneLogin を ID プロバイダとして利用 ✔ OneLogin は認証、AWS は認可を担当 ※ AWS SSO は 2022年7月に「AWS IAM Identity Center」という名称に変更されていますが、本資料では SSO のまま説明します

ユーザー、アクセス管理 - AWS SSO 導入 ■ OneLogin 管理と AWS 管理は別のチームが行っている ✔ ガバナンスの向上 ■ OneLogin 側では MFA を強制 ✔ AWS アクセスの際の認証が強固なものに

ユーザー、アクセス管理 - AWS SSO 導入 After ■ ユーザーは OneLogin 側で全て管理(管理の一元化) ■ OneLogin 側で MFA 設定を強制 ■ AWS アカウント間の移動がシームレスに ✔ 利用者は OneLogin にログインすれば良い ■ OneLogin のアカウント削除は退職と紐付いている ✔ 削除漏れのリスク低減 認証は OneLogin、認可は AWS

ユーザー、アクセス管理 - 権限の付与ルール ■ ユーザー(orグループ)には、1アカウントに対して1つのアクセス権限セットを付与 ■ 原則ユーザーに対して権限付与 ■ グループは、組織構造に依存しにくい範囲で同じ権限を付与したい場合のみ利用 ✔ 会社の組織変更の度に変更に追従する手間を省くため シンプルにすることで管理のしやすさを確保し、なるべく運用コストがかからないように

ユーザー、アクセス管理 - 権限の付与ルール

グループ ユーザー、アクセス管理

グループ名 説明 Administrators AWS の管理者用グループ。 Organizations 配下の AWS アカウント全てに Administrator 権限で ログインすることができる。 Accounting 経理メンバー用グループ。 請求周りの閲覧を行うメンバー用グループ。 AllEngineers エンジニア全員用グループ。 Workload OU 配下の全ての AWS アカウントに対する ReadOnly 権 限を付与する。 ユーザー、アクセス管理 - グループ設計

アクセス権限セット ユーザー、アクセス管理

■ 個人や組織構造を意識せず、役割に対して必要となる権限を意識して定義 ■ ここで紹介するアクセス権限セットは、あくまで設計時点のアクセス権限セット ■ 今後状況に応じて追加や変更を加えていく ユーザー、アクセス管理 - アクセス権限セット

ユーザー、アクセス管理 - アクセス権限セット 名前 権限の内容と用途 付与ポリシー Administrator Administrator 権限。 Administrators グループ(AWS 管理者用グループ) にしか付与しない。 ・AdministratorAccess(Managed) BillingCheck 請求確認用権限。 Accounting グループ(経理メンバー用グループ )にし か付与しない。 ・Billing(Managed) PowerUser PowerUser 権限。 一般エンジニアにも、本番環境以外で付与。 IAM、Organizations、Account 以外の全ての操作 が可能。 ・PowerUserAccess(Managed) ・iam:PassRole 権限等、足りない権限入りのインラインポリシー Production 本番環境用権限。 本番環境における致命的なオペレーションミスを抑止 するため、必要な権限のみ付与。 ・システムで利用している AWS サービスのフルアクセスのインラインポリシー 　　例) “ec2:*” ・禁止操作を定義したインラインポリシー 　　例) RDS のインスタンス削除禁止 等

ユーザー、アクセス管理 - アクセス権限セット 名前 権限の内容と用途 付与ポリシー AIOperation AI 業務に必要な権限。 機械学習等で必要となる権限のみ付与。 ・必要な AWS サービスのフルアクセスのマネージドポリシーを付与 　　例) AmazonSageMakerFullAccess 等 ・禁止操作を定義したインラインポリシー 　　例) S3 バケットの削除禁止 等 S3Operation S3 への操作を行うメンバー用の権限。 開発者以外のメンバーで必要な場合に割り当てる。 ・AmazonS3FullAccess(Managed) ・禁止操作を定義したインラインポリシー 　　例) S3 バケットの削除禁止 等 ReadOnly 読み取り専用権限。 ・ReadOnlyAccess(Managed) ・AWSSupportAccess(Managed)

EOF