こんにちは、クラウドセキュリティアーキテクトの大島悠司です。 7編にわたって、「Change Managerによる変更管理と本番アクセス統制」について紹介しています。 前回の「①動機づけ編」では、変更管理と本番アクセス統制の必要性を紹介しました。 AWSアカウントは、AWSリソースに対するセキュリティ、アクセス、課金の境界を提供してくれる単位です。 AWSアカウントに登録されているIAMユーザは、AWSアカウント内のリソースにアクセスできますが、外部のユーザはアクセスできません。 個人で簡単な検証をする分には単一アカウントでも十分ですが、企業で扱うワークロードの規模が大きく複雑になると、アカウントを分離したマルチアカウント構成の方が様々な恩恵を受けることができます。 マルチアカウント構成の嬉しいところを以下にあげます。 オンプレミスで、1つのワークロードに対してサーバを分離するという考えがありますが、クラウドにも同様の考えが適用できます。 代表的な切り口として、開発環境/ステージング環境/本番環境という分離方法があります。 単一アカウントの運用だと、どのワークロードがどれほど課金されているかが分かりづらくなります。 変更作業を実施した際の影響範囲を局所化することができます。まずは開発環境やステージング環境で変更作業やパッチ適用などを試したのち、本番環境へ適用することが容易になるため、サービス障害の可能性を低減できます。. マルチアカウント構成にした際に、どのようにユーザにログインしてもらうかを考えます。 それぞれのアカウントにIAMユーザを作成すると、アカウントごとにログインが必要になってしまいます。 このような場合、ユーザを1つのアカウントに集約するという方法があります。 Jumpアカウントを用意し、そこにIAMユーザを集約します。 利用者は、まずJumpアカウントにログインし、各アカウントへスイッチロールすることでログインすることができます。 権限設計の切り口は様々ですが、チームリーダーはある程度の権限を持たせたいけどチームメンバーは権限を絞りたい、というのも一つの方法です。そのような場合、以下のような設計にすると運用しやすくなると思います。 IAM設計をしたら、CloudFormationで管理することをお勧めします。 今回の「②マルチアカウント&IAM設計編」では、本番アクセス統制の前提となるマルチアカウント設計とIAM設計について紹介しました。 マルチアカウントとIAMの設計は、社内体制や事業拡大に伴い変わっていくものです。 次回の「③Session Managerログイン&ロギング編」では、エビデンス取得のためのSSHを使わないインスタンス接続やロギングについて紹介します。
今回の「②マルチアカウント&IAM設計編」では、本番アクセス統制の前提となるマルチアカウント設計とIAM設計について紹介します。
AWSアカウントとは
課金もアカウント単位で請求されます。マルチアカウント構成のメリット
セキュリティやガバナンス
こうすることで、本番環境にログインできるメンバーを最小限にしたり、各環境に適したセキュリティ対策を行うことができます。課金
アカウントを分離することで、各アカウントに対する課金が明確になり、責任範囲やコスト削減のコントロールがしやすくなります。運用
Jumpアカウント方式
前述のような、開発環境/ステージング環境/本番環境の3面構成を例にします。
さらに、IAMユーザが増えるにつれてポリシーの管理が複雑になり、セキュリティリスクが高まる要因になります。
Jumpアカウント方式やSSO方式がありますが、ここではJumpアカウント方式を紹介します。
そして、各アカウントにスイッチするロールを用意します。
各アカウントでどのような操作を許可するかは、スイッチ先のロールに対して必要な権限を付与すればよいです。
IAM設計のコツ
前提
設計ポイント解説
CloudFormationによるグループ/ロール管理
ユーザの追加時に、どのグループに入れるかを自動化しておけば、誤って不要な権限を付与することを防止できます。まとめ
周囲の動きを見ながら、組織の実態に適した設計にしておくことが大事です。「Change Managerによる変更管理と本番アクセス統制」シリーズ全編はこちら
