【AWS権限管理術③】マルチアカウント戦略でのAWS権限管理

2022.06.03

こんにちは、網中です。

5年ほど前から続けているゲームを1からやり直し始めたら、時間が吸い取られていって勉強時間が確保できていない今日この頃…そろそろ、SAP on AWSの勉強もしたいなと思いつつ、時間ばかりが過ぎていってますね…

はじめに

さて、今回はマルチアカウント戦略を推進していくあたり、抑えておくべきサービスとAWS Organizationsの権限管理方法をご紹介いたします。

複数のシステムがAWSアカウント上に構築していくとシステム担当者や運用担当者できっちり環境を分けたいというご要望が出てきたりします。しかし、IAMの仕様によりEC2を各リソースごとで制御することができなかったりとひとつのアカウントだけでは対応しきれなかったり、そもそも細々と設計するほど工数的な余裕がなかったなど…諸々問題にぶつかるかと思います。

そういった方には、ぜひマルチAWSアカウントのご利用を考えていただきたい！
マルチアカウントを利用すれば、複数の階層で権限を管理できるようになる為、非常に便利且つよりセキュアなAWS環境をご利用することができます！

AWSマルチアカウント戦略とは

簡単に言うと「用途・基準に合わせて、AWSアカウントを分割すること」です。
AWSアカウントを分けることで、ガバナンスをきっちり切り分けることができたり、何かトラブルがあった際に影響範囲縮小することができます。

AWSマルチアカウント戦略の詳細について、良いサイトがゴロゴロ落ちておりますので、下記サイトを含めご確認いただけますと幸いです。

AWS マルチアカウント管理を実現するベストプラクティスとは ? - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
AWS が変化を求めるデベロッパーの皆様を応援するウェブマガジン。毎月更新する記事で新たなスキルや他のデベロッパーが抱える課題と解決方法に迫るインタビューをご覧いただけます。
aws.amazon.com

 

AWSマルチアカウント戦略で抑えておくべきAWSサービス５選

AWS Organizations

複数のAWSアカウントを統合するためのアカウント管理サービスです。権限設計をするのであれば抑えておくべきサービスです。
機能的には後述するサービスコントロールポリシー（SCP）で権限管理や、顧客ニーズに合わせたアカウントの階層的な管理が可能になります。

AWS Organizations（AWS アカウント全体の一元管理）| AWS
AWS Organizations は、AWS リソースの増加とスケールに合わせて、一元化されたクラウドアカウント管理を可能にします。
aws.amazon.com

 

AWS Single Sign-On (AWS SSO)

AWS組織全体のアクセスを一元管理するサービスです。使用感は少し違いますが、IAMの複数アカウント版みたいな認識でいていただけたらと思います。アカウント切り替えるごとにログアウト・ログインやスイッチロールする手間を省くことができます。

シングルサインオン SAML - SSO プロバイダー - AWS IAM アイデンティティセンター - AWS
IAM アイデンティティセンターでは、ワークフォースの ID を安全に作成または接続できます。これにより、AWS アカウントやアプリケーションへのアクセスを一元的に管理できます。
aws.amazon.com

 

AWS Control Tower

複数あるAWSアカウントのガバナンスを統合して管理したいときに利用するサービスになります。
例えば複数アカウントにSCPを適用したり、Configを一括適用したりなど、セキュリティ機能の有効化やログの集約が可能です。

AWS Control Tower（複数アカウント環境をセキュアに設定、管理）| AWS
AWS Control Tower は、セキュリティ、オペレーション、およびコンプライアンスのルールを使用して AWS ワークロードを管理する、優れた設計のマルチアカウント環境を設定するための単一の場所を提供します。
aws.amazon.com

 

AWS Security Hub

AWSの対象サービスのアラートを一元管理する仕組みを持つサービスになります。複数のサービスで発生したセキュリティアラートの集約や整理優先順位寺家を行い一つの管理画面で分かりやすく見ることができます。

AWS Security Hub（統合されたセキュリティ & コンプライアンスセンター）| AWS
AWS Security Hub は、ベストプラクティスのチェックを自動化し、アラートを集約して、自動修復をサポートするクラウドセキュリティ体制管理サービスです。
aws.amazon.com

 

AWS Resource Access Manager

EC2キャパシティ予約やVPCエンドポイントなど、アカウント間でリソースを利用できるサービスです。

AWS Resource Access Manager（AWS リソースを簡単かつ安全に共有）｜ AWS
AWS Resource Access Manager は、他の AWS アカウントと AWS リソースを安全に共有するのに役立ちます。
aws.amazon.com

 

以降は、AWSマルチアカウント戦略で考えることになる権限管理周りについて深堀りしていこうと思います。

マルチアカウントでの要となる権限管理サービス【AWS Organizations】

Organizationsでは、AWSの権限管理のレイヤーでいうとこの辺りの権限階層を設計するためのサービスであるサービスコントロールポリシー（SCP）を提供しております。

SCPでは、ざっくりと権限のガードレールを設定すると良いと思いますが、メンバーアカウントからは操作できないといったメリットがある為、Organizationsで権限管理を固めるような設計もできたりします。

メリットを踏まえて、SCPで考えるべきポイントとしては以下項目があるかと考えております！

★ 最優先の検討ポイント
  • 利用させないサービスと機能の検討
    例）LambdaのFunctionURL機能の禁止、特定のインスタンスタイプの利用禁止　などなど…
★ Organizationsでなるべく権限管理を固めたい方向けの検討ポイント
  • IAM権限の制御の検討
  • NW権限の制御の検討
  • 利用できるリージョンの制御の検討　　　などなど…

なおSCPで権限設計をするにあたり、いくつか注意事項がありますので、以下制限事項も念頭に置いておきましょう！

 

SCPの制限

  • 管理アカウント(支払いアカウント)には適用不可です。※Organizationsが操作できるアカウントはSCPで制御できません。
  • SCP はメンバーアカウントのルートユーザーを含む、メンバーアカウントの IAM ユーザーとロールのアクセス許可を制限します。
  • SCPでは以下の構文がDenyでしか使えない構文・そもそもサポートされていない構文がある為、そこも押さえておきましょう。
    • Denyのみ対応
      • NotAction：SCP から除外される AWS のサービスおよびアクションを指定します。
      • リソース：SCP が適用される AWS リソースを指定します。
      • Condition：ステートメントを実行するタイミングの条件を指定します。
    • サポートされていない要素
      • Principal
      • NotPrincipal
      • NotResource
  • ステートメント「Sid」では、英文字・数字のみ対応しています。[_]や[-]といった記号が利用できません。
    • 特にSidで引っかかっているときのエラーが非常に分かりにくいので、覚えておいた方が良いです。私はここで、2～3時間程引っかかっていたことがあります。
    • SCP構文詳細は　下記をご参照ください。
SCP 構文 - AWS Organizations
組織の一部であるアカウントで、ユーザーとロールが実行できることを制限するための AWS Organizations サービスコントロールポリシー (SCP) の構文について説明します。
docs.aws.amazon.com
  • すべてのアカウントには、その上位のすべての親で許可されている必要があります。つまり、OUがある分権限のフィルターが増えていくようなイメージです。　例えば以下のような階層構造のAWSアカウント構成だとします。

    そうなると、権限のフィルターは下のようなイメージになります。

だいぶ階層が深くなってきましたね…
その分上の方ではだいぶざっくり管理でも下の階層で固有の設定ができる事が見て分かると思います。

但し、階層が深くなるとバグを引き起こしている箇所を見つけにくくなるといったデメリットがある為、必ず階層ごとで制御した内容を分かるようにして、検証環境でテストしてから本番環境に適用するようにしましょう。

IAM権限を制御する場合の注意点

IAMの権限については、権限昇格できないようしっかりと管理しておきたいもの…
ただ、IAMロールの作成やIAMユーザのアクセスキーの払い出しについてはAWSで利用する上で必要になる場面があることと反面、無為にIAM:*で権限を与えれば、LambdaやEC2から権限昇格できてしまう可能性があり、なかなか難しいところです。

マルチアカウントのIAM権限管理する方法は２パターンが考えられます。

  1. AWS ControlTowerで、IAMロールが作成された場合に管理者に通知が飛ぶように設定を行う
  2. Organizationsで詳細な権限設計を行う。

パターン１を選んだ場合、IAMロールが作成される都度通知が飛び、権限昇格できるようなロールが作成されていないか確認することができます。ただし、未然に防ぐことはできず、環境が増えれば増える程管理が難しくなります。

パターン２の場合は、利用するサービスの必要な権限をあらかた洗い出す必要がある為、最初の設計が大変です。
但し、一回設定してしまえば、その後の運用の手間をかなり削減することができます。

一長一短ありますが、パターン2を実装する場合の権限設計を記載致します。あくまでサンプルですので、必要な権限について検討・検証した上で実装いただけますと幸いです！！

  • IAMの制御用ポリシー
{
　"Effect": "Deny",
　"Action": [
　　"iam:CreateUser",
　　"iam:DeleteUser",
　　"iam:UpdateUser",
　　"iam:AddUserToGroup",
　　"iam:RemoveUserFromGroup",
　　"iam:AttachUserPolicy",
　　"iam:DeleteUserPolicy",
　　"iam:DetachUserPolicy",
　　"iam:PutUserPermissionsBoundary",
　　"iam:DeleteUserPermissionsBoundary",
　　"iam:CreateAccessKey",
　　"iam:DeleteAccessKey",
　　"iam:GetAccessKeyLastUsed",
　　"iam:PutUserPolicy",
　　"iam:ListAccessKeys",
　　"iam:UpdateAccessKey",
　],
　"Resource": [
　　"*"
　],
　"Condition": {
　　"StringNotLike": {
　　　"aws:PrincipalArn": [
　　　　"arn:aws:iam::*:role/Admin",
　　　　"arn:aws:iam::*:user/Admin",
　　　　"arn:aws:iam::*:root"
　　　]
　　}
　}
}
  • 説明
    本ポリシーでは、IAMユーザの操作権限とアクセスキーの操作権限を特定のユーザ・ロールからのみ操作できないように設定しております。なお、特定のユーザ・ロールが削除されてしまったり、変更されてしまった場合、操作ができなくなる可能性がある為、以下のような特定のユーザ・ロールを操作できないような設定を合わせて記載しておくことをお勧めします。
{
　"Effect": "Deny",
　"Action": [
　　"iam:*"
　],
　"Resource": [
　　"arn:aws:iam::*:*/Admin",
　],
　"Condition": {
　　"StringNotLike": {
　　　"aws:PrincipalArn": [
　　　　"arn:aws:iam::*:role/Admin",
　　　　"arn:aws:iam::*:user/Admin",
　　　　"arn:aws:iam::*:root"
　　　]
　　}
　}
}

ネットワーク関連権限の注意点

VPC関連の権限は、EC2にまとまってしまっている為なかなか判別がめんどくさい…ということで、NWに関わりそうなアクションの一覧を作りました！利用される際は、制御が必要な権限をピックアップ・ご検証いただいた上で利用ください。

EC2におけるネットワーク権限一覧
ダウンロード413 Downloads

利用できるリージョンの制御

利用するリージョンを制御したい場合は、下記のようにグローバルサービスをNotAcctionに入れて、ws:RequestedRegion以下に利用するリージョン名をご記入いただけるかと思います。

なお、グローバルサービスは適当にピックアップしている為、抜けがある可能性がございます。検証いただいた上でご利用いただけますと幸いです。

{
　"Effect": "Deny",
　　"NotAction": [
　　　"iam:*",
　　　"directconnect:*",
　　　"cloudtrail:*",
　　　"sts:*",
　　　"support:*",
　　　"health:*",
　　　"trustedadvisor:*",
　　　"organizations:*",
　　　"route53:*",
　　　"aws-marketplace:*",
　　　"aws-portal:*",
　　　"servicequotas:*",
　　　"s3:*"
　　],
　"Resource": [
　　"*"
　],
　"Condition": {
　　"StringNotEquals": {
　　　"aws:RequestedRegion": [
　　　　"ap-northeast-1",
　　　　"ap-northeast-3"
　　　]
　　}
　}
}

さいごに

いかがでしたでしょうか。

だいぶ盛りだくさんになってしまいましたが、マルチアカウントのご利用を考えている方の後押しができましたら、幸いです。

 

タイトルとURLをコピーしました