AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法 ～5. GuardDuty～
Organizationsシリーズ第五弾、Amazon GuardDuty編です。
GuardDutyとは
マネージド型の脅威検出サービスです。AWSアカウント内で発生している脅威を検出してくれます。たとえば以下のような事象を検知してくれます。
- ルートユーザの使用
- IAMユーザーの不正利用(大量の操作実行など)
- EC2の不正通信
検知する仕組みはAWS側で管理されるので、利用者はそれをどう検知、管理していくか運用面を検討して利用すればOKです。 デフォルトで有効にしたいサービスの１つですね。
Organizationsを使用したマルチアカウント設定
GuardDutyもAWS Configと同じく、アカウントの委任に対応しています。よって以下のようにauditアカウントに情報を集約できます。
手順の流れは以下のとおりです。
- メンバーアカウントへ委任
- メンバーアカウントのGuardDuty有効化、新規アカウントの自動有効化
- (Option) 検知の設定
設定手順
実際にやっていきます。
1.メンバーアカウントへ委任
マネジメント（親）アカウントへログインし、GuardDuty画面へ遷移します。
まだマネジメント（親）アカウントでGuardDutyが有効でない場合は有効化しておきます。
有効にした後、設定＞委任された管理者欄に委任先のアカウントIDを入力し、委任ボタンを押します。
委任が完了すると以下のような画面表示になります。
2.メンバーアカウントのGuardDuty有効化、新規アカウントの自動有効化
委任後、委任したアカウントauditにログインしてGuardDuty画面へ遷移します。すると、audit以外のアカウントが表示されます。
組織単位でGuardDutyを有効にできるボタンが表示されるので、有効化を押します。
※なお、auditアカウントはGuardDuty無効状態でしたが、委任をした時点で自動的に有効化されました。
確認が以下のように出るので有効化します。有効にすることで今後新規で追加されるAWSアカウントもGuardDutyが有効になります。
しばらくすると以下のように各アカウントのステータスが有効になります。
GuardDutyにはS3へのデータアクセスに対する脅威も検出できる（最近できるようになった）のですが、この有効化は別管理となっています。これの自動有効化も同画面からできそうなのでやってみます。
チェックを入れて更新。
と、これで既存のアカウントも有効になると思ったのですが、そうではないようです。新規アカウントの自動有効設定でした。
既存アカウントはS3保護の設定から有効化します。
できました。
アカウント側にも反映されています。
GuardDuty有効の設定はここまでです。
なお、ここまでの設定では東京リージョンのみ有効となっています。脅威はどのリージョンでも発生する可能性があるため、可能であれば全リージョンでの有効も検討したほうが良いでしょう。具体的なやり方は自動化の検討をする機会があれば書いてみたいと思います。（全サービス書き終えて余裕があれば書いてみる予定です）
3. 検知の設定
有効化しただけではGuardDutyの本来の脅威検出の機能が見れないので、サンプルイベントの検知を行ってみます。
通知の設定はEventBridgeから行います。
イベントパターンで以下のようにGuardDuty Findingを設定します。これによりGuardDutyのすべての検知がイベントとしてトリガーされます。
ターゲットに通知用のSNSを指定して、ルールを作成します。今回はあらかじめChatbotを設定しておいたSNSを指定します。（Chatbotの設定方法は本記事では割愛）
メールを設定したSNSでもOKです。
ルールができました。
サンプルイベントを発行してみます。全アカウントのGuardDuty検知がauditアカウントに集約されて検知されるはずなので、今回は別アカウントのsystem01でサンプルイベントを発行してみます。
system01アカウントにログインし、GuardDuty画面からサンプルイベントを発行します。
しばらくすると以下のように通知が飛んできます。Accountのところに対象のアカウント、今回でいうとsystem01のアカウントIDが表示されます。
つまり、以下のように、集約されたauditアカウント経由で通知されたことになります。
アカウントが増えても自動的に有効になるので組織単位の通知運用が可能になりますね。
すべてのFindingを通知すると量も多くなりますのでフィルタの検討も必要にはなるかと思います。
以上、検知も含めた設定の検証はここまでです。
さいごに
AWS Config、CloudTrailに比べてすんなり設定できた印象です。マルチアカウントの要望が強いサービスなのかもしれませんね。
GuardDutyは有効にするだけで、AWSが裏側で色々動いて色々な脅威を検知してくれるので、私もとても好きなサービスです。 この機能を使ってうちの組織はデフォルトでONだから！といった管理運用も良いですね。
次回はIAM Access Analyzerの予定です。
AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法 ～4. AWS Config～
Organizationsシリーズ第四弾、AWS Config編です。
AWS Configとは
AWSリソースの設定変更履歴を保存できるサービスです。たとえばあるセキュリティグループに対して、誰がどのような変更を行ったのか履歴で確認できます。
また、Configルールと修復アクションを使用することで、リソースが指定された状態になっているかチェックを行い、自動的に修復することも可能です。たとえば、セキュリティグループで0.0.0.0/0が設定されてインターネットに公開された場合に検知して自動削除するといった運用も可能になります。
Organizationsを使用したマルチアカウント設定
前提として、Config記録が全アカウント、全リージョンで有効になっている必要があります。 以下の手順で実施していきます。
- Organizationsの「信頼されたアクセス」有効化
- メンバーアカウントへ委任
- アグリゲータの作成
- (Option) Configルールの組織適用
Configはアカウントの委任をサポートしているため、集約するアカウントをマネジメントアカウント以外のアカウントに設定できます。
設定手順
1. 「信頼されたアクセス」有効化
Organizationsの設定のため、マネジメントアカウントで実行します。
Configルールで必要なconfig-multiaccountsetup.amazonaws.comの設定が現状CLIのみ実行可能なようなので、CLIで実行します。今回は手軽にCLIが実行できるCloudShell上で実行しました。
有効化コマンド：
$ aws organizations enable-aws-service-access --service-principal config.amazonaws.com $ aws organizations enable-aws-service-access --service-principal config-multiaccountsetup.amazonaws.com
確認コマンド：
$ aws organizations list-aws-service-access-for-organization --output text | grep config ENABLEDSERVICEPRINCIPALS 2020-12-22T04:00:11.418000+00:00 config-multiaccountsetup.amazonaws.com ENABLEDSERVICEPRINCIPALS 2020-12-22T02:27:53.842000+00:00 config.amazonaws.com
2. メンバーアカウントへ委任
こちらも同じくCLIで実行します。
※コマンド上の[委任アカウントID]は実際の環境に合わせて修正が必要です。
委任コマンド：
$ aws organizations register-delegated-administrator --account-id [委任アカウントID] --service-principal config.amazonaws.com $ aws organizations register-delegated-administrator --account-id [委任アカウントID] --service-principal config-multiaccountsetup.amazonaws.com
確認コマンド：
$ aws organizations list-delegated-services-for-account --account-id [委任アカウントID] --output text | grep config DELEGATEDSERVICES 2020-12-22T04:31:39.050000+00:00 config-multiaccountsetup.amazonaws.com DELEGATEDSERVICES 2020-12-22T04:31:31.375000+00:00 config.amazonaws.com
3. アグリゲータの作成
委任が完了したので、委任した監査アカウント上でアグリゲータを作成します。Configの画面上から作成できるため、GUIで実行します。
アグリゲータとは、複数アカウントのConfigの情報を集約して確認、設定できる機能です。
データレプリケーションを許可して、任意のアグリゲータ名を入力します。
組織を追加するを選択して、IAMロールを選択します。IAMロールはあらかじめ用意されているものを選びました。
すべてのリージョンを選択して保存します。
しばらく時間を置いて、アグリゲータの画面を見てみると、組織内の全アカウントのリソースが表示されます。 リソース名をクリックすると、各リソースの詳細も確認できます。
4. Configルールの組織適用
Configルールの組織単位の適用は、Configの画面上から設定できそうな項目は出てきませんでした。CLIで実行できそうなので、委任アカウントのCloudShellを使用してルールを作成してみます。
今回はAWSが管理しているルールであるguardduty-enabled-centralized (GuardDutyが有効になっているか）を使用します。Description内容はConfigマネージドルールで記載されている内容そのままです。
実行コマンド：
aws configservice put-organization-config-rule \ --organization-config-rule-name org-guardduty-enabled-centralized \ --organization-managed-rule-metadata \ Description="AWS アカウントおよびリージョンで、Amazon GuardDuty が有効になっているかどうかを確認します。一元管理用の AWS アカウントを指定した場合、ルールはそのアカウントでの GuardDuty の結果を評価します。GuardDuty が有効であれば、ルールは準拠しています。",\ RuleIdentifier="GUARDDUTY_ENABLED_CENTRALIZED"
実行結果：
{ "OrganizationConfigRuleArn": "arn:aws:config:ap-northeast-1:[委任アカウントID]:organization-config-rule/org-guardduty-enabled-centralized-tvymtmkq" }
しばらくしてConfigの集約ビューからルールを確認すると、以下のとおり組織内の3アカウントのルール準拠状況が確認できます。2アカウントでGuardDutyが有効になっていないです。良くないですね。
なお、ルール単体ではなくルールの集合である適合パックを適用する場合は、以下のコマンドで実行できます。
今回の例ではAWS側のサンプルにある「Operational Best Practices for Amazon S3」を適用しています。 コードはgithub上に上がっているのでそれをダウンロードしておきます。以下のコマンドではcurlコマンドでテンプレートをダウンロードしています。
実行コマンド：
# テンプレートダウンロード $ curl -LO https://raw.githubusercontent.com/awslabs/aws-config-rules/master/aws-config-conformance-packs/Operational-Best-Practices-for-Amazon-S3.yaml # 適合パック適用 aws configservice put-organization-conformance-pack \ --organization-conformance-pack-name org-s3-bestpractice \ --template-body "file://Operational-Best-Practices-for-Amazon-S3.yaml"
実行結果：
{ "OrganizationConformancePackArn": "arn:aws:config:ap-northeast-1:[委任アカウントID]:organization-conformance-pack/org-s3-bestpractice-52tw7yqa" }
適用された適合パックは以下のように見えます。適合パックに含まれる複数のルールが表示されています。
設定手順はここまでです。
さいごに
個人的には、ConfigはCloudTrailと同じくらいセキュリティ的に重要なサービスです。今回の記事ではOrganizationsを使用して組織内のすべてのアカウントに対して情報集約、ルール設定する方法を紹介しました。
Configルールを合わせて活用することで、組織全体の予防的統制、発見的統制に役立つことができると思います。AWSからも様々なルールが公開されていますので、まずは自分の組織に適用できるルールがないか確認し使用していくところから始めると良いと思います。
次回はGuardDutyの予定です。
AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法 ～3. CloudTrail～
あけましておめでとうございます。2021年1つ目のブログは、Organizationsシリーズ第三弾です。今回はCloudTrailです。
CloudTrailとは
AWS上の操作履歴を保存し、可視化できるサービスです。デフォルト状態で、特に何もしなくても過去90日分は操作履歴を確認できます。追加で証跡という設定を行うことで、すべての操作履歴をS3バケットに保存して確認できるようになります。
シングルアカウントの場合、当たり前ですが有効にすると自アカウントの操作証跡が指定したS3バケットに保存されます。
Organizationsを使用した証跡の有効
Organizationsを使用すると、組織内のすべてのアカウントに対してCloudTrailの証跡を有効にして、指定したS3バケットにすべてのアカウントの証跡が保存されます。
なお、現時点でCloudTrailはアカウントの委任機能に対応していないため、組織単位の証跡有効および保存先の設定はマネジメントアカウントで実行する必要があります。
設定方法
実際の設定方法は簡単です。CloudTrailの証跡を有効化する際に、「組織内のすべてのアカウントについて有効化」にチェックを入れればOKです。その他の設定項目はシングルアカウントの設定時と同様のため詳細手順は割愛します。基本は画面のとおり進めていけばOKです。
作成が完了すると、以下のように組織の証跡が「はい」の状態で表示されます。
連結（メンバー）アカウントからの見え方
Organization配下の連結アカウントからCloudTrailの証跡を見ると、マネジメントアカウントと同じように証跡が設定されています。
ただし、証跡の削除や設定変更ができない旨も合わせて表示されます。強制的にマネジメントアカウントによって証跡が残るのは良いですね。
S3バケット内の証跡ファイルを確認しようとすると、以下のようにエラーとなります。これはバケットポリシーでマネジメントアカウント外のアカウントから許可がされていないためです。
連結アカウントから自アカウントの証跡を確認するためには、別途追加の設定が必要になります。方法はいくつかあるため後ほど考察してみます。
ひとまず、全アカウントでの証跡強制有効、マネジメントアカウントでの一元管理ができました。
監査アカウント上のバケットに保存
マネジメントアカウント上のS3バケットではなく、ログやセキュリティ情報を格納する監査（audit）アカウントのS3バケットにCloudTrailの証跡を集約してみます。
まず、監査アカウントにログインしてS3バケットを作成します。名前以外はデフォルトで設定しておきます。
今回はバケット名に「202012cloudtrail-audit-organization」という名前を設定しています。
アクセス許可のタブに移動し、
バケットポリシーを編集します。
ポリシーは以下のとおり設定します。マネジメントアカウントで証跡有効をした際に自動設定されたバケットポリシーを参考にしています。
※[ManagementAccountID]と[OrganizationID]は置き換えが必要です。OrganizationIDは、Organizations>アカウントの整理画面で右側のARN情報に見える、「o-」で始まる文字列です。
※バケット名は今回「202012cloudtrail-audit-organization」としているのでそのまま記載していますが、ここも実環境に応じて変更が必要です。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AWSCloudTrailAclCheck20150319", "Effect": "Allow", "Principal": { "Service": "cloudtrail.amazonaws.com" }, "Action": "s3:GetBucketAcl", "Resource": "arn:aws:s3:::202012cloudtrail-audit-organization" }, { "Sid": "AWSCloudTrailWrite20150319", "Effect": "Allow", "Principal": { "Service": "cloudtrail.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::202012cloudtrail-audit-organization/AWSLogs/[ManagementAccountID]/*", "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" } } }, { "Sid": "AWSCloudTrailWrite20150319", "Effect": "Allow", "Principal": { "Service": "cloudtrail.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::202012cloudtrail-audit-organization/AWSLogs/[OrganizationID]/*", "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" } } } ] }
バケットポリシーの設定が完了したら、マネジメントアカウントに戻ります。
※アカウントを行ったり来たりするので間違えないように注意です。
先ほどの手順と同じく、組織のCloudTrail証跡を作成します。
このとき、バケット名に先ほど監査アカウントで作成したバケット名「202012cloudtrail-audit-organization」を既存のバケットとして指定します。
作成が完了すると以下のようにauditと名前のついた証跡が作成されていることが確認できます。比較用に先ほどマネジメントアカウント上で作成した証跡も残しています。
以下のように、監査アカウントにCloudTrail証跡を集約することができました。バケット内のオブジェクトは、監査アカウント内からしか見えません。マネジメントアカウントからも見えなくなります。
CloudTrailはサービスとしてアカウントの委任機能に未対応ですが、このようにバケットを意図的に他アカウントに指定することで委任のような設定を行うことができます。
他アカウントでの証跡の確認方法
1アカウントに証跡を集約できましたが、集約されたアカウント以外はS3バケット内の証跡を確認できませんでした。これを確認できるようにするにはどうすれば良いでしょうか。いくつか考えてみます。
1. 証跡確認用IAMロールを作成する
これはAWSの公式ドキュメントにも記載のある方法です。図もそこから引用させてもらいます。
集約されたアカウントにIAMロールを作成し、そのロールに別アカウントからスイッチしてくるという運用ですね。
アカウントが増えるたびに、専用のロールも合わせて作成する必要があります。
2. バケットポリシーを変更する
集約されたS3バケットのバケットポリシーで他アカウントからのs3:GetObjectとs3:ListBucketを許可すれば参照が可能です。アカウントIDで許可する必要があるため、こちらもアカウントが増えるたびにバケットポリシーの変更が必要になります。
もしくは、組織内全体でログが確認できてOK（自分のアカウント以外のログが見えてもOK）であれば、OrganizationのIDを指定してアクセス許可することも可能です。
運用ポリシーとして全てのログが見えてOKであれば、おススメの設定です。 具体的には以下のようにバケットポリシーに追加すればOKです。
※Statementの1ブロックを抜粋しています
※[OrganizationID]にはご自身のOrganizationID（o-で始まる文字列）の入力が必要です。バケット名も環境に合わせて修正してください
{ "Sid": "FromOrganization", "Effect": "Allow", "Principal": "*", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::202012cloudtrail-audit-organization", "arn:aws:s3:::202012cloudtrail-audit-organization/*" ], "Condition": { "StringEquals": { "aws:PrincipalOrgID": "[OrganizationID]" } } },
設定が完了すると組織内のすべてのアカウントから以下のようにS3内のオブジェクトが確認できます。
3. 各アカウントごとに証跡を作成する
CloudTrailの証跡は複数作成できるので、組織設定で全体として取得しつつ、各アカウントごとに単独で設定することも可能です。 こうすることで、各アカウント内で自分のアカウントのみ証跡を確認できるといった運用も可能です。
証跡が重複して作成されますので、S3の料金が多くなる点には注意が必要です。個人的には、S3の料金は高くないので大きく気にするほどでもないかと思います。
アカウント単位の設定が必要にもなりますが、これはCloudFormationのStaclSetsを活用することでアカウント作成時に自動化することも可能です。 アカウント単独で証跡の運用が必要な場合は、おススメな構成です。
他アカウントからの参照方法は以上３パターンです。どれにするかは私としても悩みどころですが、マッチするパターンがあれば幸いです。
さいごに
セキュリティおよび監査要件ではとても重要であるCloudTrail。証跡機能は基本的に有効化するものとして、それをどう運用していくか検討が必要ですね。 特にマルチアカウントになった場合は一元管理の方法も要検討です。
今回はS3に集約するところまで確認しましたが、実際の運用ではAmazon Athenaなどを使用して、可視化を行って運用していく必要があります。
今回はここまで。次回はConfigの予定です。
AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法 ～2. コスト管理～
Organizationsシリーズ第二弾です。今回はコスト（利用料）管理についてです。
シングルアカウントの場合
シングルアカウントでは、コストの可視化のために以下の設定を行います。
Organizationsを使用している場合はどうなるのか見ていきます。
IAMユーザーの請求情報アクセス許可
デフォルトではIAMユーザーは請求情報にアクセスできず、ルートユーザのみアクセスが可能です。
右上のアカウント名＞マイアカウントを順に選択してアカウント設定ページへ遷移し、ページ下部にある「 IAM ユーザー/ロールによる請求情報へのアクセス」をアクティブ化することで、IAMユーザーが参照可能になります。
Organizationsを使用している場合は、マネジメントアカウントでこの設定を行うことで、Organizations配下のすべての連結アカウントで請求情報へのアクセスが有効になります。そのため、最初にマネジメントアカウントで有効にすればOKです。
マネジメントアカウントから請求の画面を確認すると、以下のようにアカウント単位の利用料も確認できます。
連結アカウント内で請求情報を確認すると、シングルアカウント運用時と同様に、自アカウントの利用料のみ表示されます。
Cost Explorerの有効化
Cost Explorerは、AWS利利用を月別、日別やサービス別で確認できるツールです。IAMユーザーの請求情報アクセス許可同様に、マネジメントアカウントで有効にすることで配下の連結アカウントでもCost Explorerが使用できるようになります。
請求同様に、マネジメント（親）アカウントから見ることで、アカウント単位のコスト確認も可能です。もちろん組織全体としてのコスト分析も可能です。
また、マネジメント（親）アカウントのCost Explorer＞設定では、配下の連結アカウント内で表示できる情報を設定できます。
たとえば、マネジメント（親）アカウントで利用料割引となるクレジットや返金が適用されると、それらの割引はOrganizations全体に渡って各アカウントに分配されますが、これらの割引情報を連結アカウント内では表示できないように設定できます。割引情報はマネジメント（親）アカウントで管理し、配下の連結アカウントでは実際に利用料としてかかっているコスト（割引なし）を管理するといった運用が可能になります。
予算およびアラートの設定
あらかじめ想定した利用料を決めておき、想定した利用料を超えたらアラートを行うといった設定がAWS Budgetsで可能です。
このBudgetsの設定は、マネジメントアカウントで組織全体として設定も可能ですし、連結アカウント内でアカウント単体としてのBudgetsも設定可能です。
マネジメントアカウント（組織全体）と各連結アカウントでコスト管理担当がそれぞれいる場合は、組織全体、アカウント単体それぞれで設定して管理していくと良いでしょう。
マネジメントアカウントの予算設定で、特定のアカウントを指定した設定も可能です。
OUの指定はできませんでしたが、組織内のいくつかのアカウントをまとめたコストを管理したいといった場合に利用できそうです。
さいごに
マネジメントアカウントと連結アカウントという言葉が頻繁に出てきて、ちょっと混乱しますが、まとめると以下のとおりです。
- コストサービスの有効化はマネジメント（親）アカウントで有効にすればOK
- 有効化後のコスト管理は、組織全体でもアカウント単体でも可能
コスト管理はクラウドではとても重要な運用項目となりますので、これらのサービスを使用してうまく管理していきたいですね。
次回はCloudTrailについて見ていく予定です。
AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法 ～1. IAM、AWS SSO～
Organizationsを活用したセキュリティサービスの活用、第一弾は認証・認可にかかわるIAMとAWS SSOについて見ていきたいと思います。
シングルアカウントの場合
AWSアカウントを1つで運用する場合、ユーザーの認証・認可では以下の対応が必要になります。
- ルートユーザの保護
- 管理者および利用者のIAMユーザーの作成
それぞれマルチアカウントになるとどうするのが良いのか見ていきたいと思います。
ルートユーザの保護
ルートユーザとは、AWSアカウント作成時に設定したメールアドレスとパスワードでログインできるユーザのことを指します。Organizations経由でAWSアカウントを作成した場合も、ルートユーザは同じく存在します。
このルートユーザを保護するために、「強力なパスワードの設定」と「多要素認証（MFA）の有効化」を行いますが、現時点でOrganizationsから複数アカウント一括でこの設定をする方法はありません。そのため、各アカウントのルートユーザーでログインしてパスワードおよびMFAの設定を行う必要があります。
Organizationsからアカウントを作成した場合、AWS側でランダムにルートユーザーのパスワードが設定されます。利用者にこのパスワードは通知されないため、パスワードの初期化を行ってログインを行います。
ログイン後、MFAの有効化を行います。
MFAの設定以外にもルートユーザのみ設定可能な以下のような項目は合わせて設定しておくと良いでしょう。
※追記：請求情報、Cost Exploerはマネジメントアカウント側で有効にすることで組織内のアカウント全てで有効になります。
- IAMユーザーの請求情報アクセス許可 →マネジメント（親）アカウントのみでOK
- Cost Explorerの有効化 →マネジメント（親）アカウントのみでOK
- サポートプランの変更
ここまではシングルアカウントでやっていた作業を各アカウントそれぞれで実施するだけですね。
Organizationsを使用してルートユーザの保護方法として、Service Control Policy（SCP）を使用する方法もあります。
SCPは前回の記事でも記載のとおり、複数のアカウントにまとめてIAMポリシーのような形でポリシーを記載して、実行できる操作を制限できる機能です。
AWSの公式ドキュメントにも以下のような例があり、この例ではルートユーザのEC2操作をDenyしています。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "RestrictEC2ForRoot", "Effect": "Deny", "Action": [ "ec2:*" ], "Resource": [ "*" ], "Condition": { "StringLike": { "aws:PrincipalArn": [ "arn:aws:iam::*:root" ] } } } ] }
ただし、すべてのルートユーザの操作を拒否できるわけではないため注意が必要です。拒否が効かない内容は以下のドキュメントに書いてあります。
ルートユーザの保護はここまでです。
IAMユーザの作成、管理
シングルアカウントの場合、アカウント内の利用用途に応じて、用途ごとにIAMグループを作成し、個人ごとのIAMユーザーをグループに適用していくのが良いかと思います。 複数アカウントになった場合、アカウントごとにIAMユーザーを作成していくと、認証情報（ID、パスワード、アクセスキー）が多くなり、管理も煩雑になります。 認証情報が多くの場所にできると、セキュリティリスクにもなります。
そこで認証情報の一元管理ができ、Organizationsとも連携できる機能がAWS SSO（AWS Single Sign-On）です。概要と開始方法を書いていきます。
AWS SSOとは
AWS SSOは、複数AWSアカウントの認証情報を一元管理してシングルサインオンの機能を提供するサービスです。 ID、パスワードはもちろん、認可の情報（IAMポリシー、どのActionができるか）も合わせて一元管理できるすばらしいサービスです。
実際の設定と画面を見たほうがわかりやすいと思いますので、開始方法をまずは書いていきます。
AWS SSOの開始方法
以下のような構成で試していきます。マネジメント配下に2アカウントあり、それぞれ別のOU（組織単位）に属しています。 OUには複数アカウント所属することも可能です。
AWS SSOは、アカウントの委任には対応していないため、マネジメントアカウント上で設定する必要があります。
なお、AWS SSOで管理するIDはMicrosoft Active Directoryなど、外部のIDプロバイダーを指定することも可能です。今回はAWS内でできる限り完結するために、AWS SSO内でIDの設定を行いたいと思います。
Azure ADでの設定方法は以下の記事で書いていますので、参考にしてもらえればと思います。（一部設定作業は今回と同様になります。）
それでは設定していきます。 マネジメント（親）アカウントのIAMユーザーでログインします。
AWS SSO画面に遷移し、有効にします。
Organizationsの組織が作成されていない場合は、以下のとおり表示されます。 AWS組織の作成を押すことで、組織が自動作成されます。
Organizations側から組織を作成済みであればこの画面は出ないかと思います。
組織の新規作成時は、メールの検証が必要となるため、アカウントのメールアドレスに届いたメールを確認して青いボタンを押しておきます。
30秒ほどでSSOの設定は完了すると思います。
ユーザー、グループの作成
ユーザー単独ではなくグループ単位で権限管理するため、まずはグループを作成します。
管理者用にadminというグループを作成します。
続いてはユーザーです。
必須項目であるユーザー名、メールアドレス、氏名情報のみ入力します。
先ほど作成したadminグループに所属させ、ユーザーを追加します。
以下のように登録したメールアドレスにメールが届くので青いボタンを押しておきます。
パスワードを設定してログインはできますが、まだAWSアカウントの設定をしていないためアプリケーションが無いと表示されます。
アクセス権限セットとアカウントの設定
AWSアカウントにログインできるよう設定していきます。まずは権限を設定するアクセス権限セットです。
今回はAWS側で職務単位で用意されている職務機能ポリシーを使用します。
※本番運用時は、必要な権限を決めて最低限の権限となるように付与しましょう。
管理者用にAdministratorAccessを付与します。
タグは特に設定せず、内容確認して作成します。
作成できました。
続いてログインする対象のアカウントを選択します。 アカウント一覧はOU単位で表示されます。今回はsystem01アカウントとauditアカウントの2つを選択して、ユーザーを割当します。
作成しているグループadminに割当します。
作成した権限セットを選択して完了します。
しばらくするとアカウント側の設定が完了します。詳細を見ると、アカウント側でIAMロールが作成されていることがわかります。
MFAの設定
ログイン時にMFAを強制するよう設定します。ここも一括でできるのがAWS SSOの魅力ですね。
サインインのたびに要求し、登録がない場合は登録を要求するようにして保存します。
ログイン確認
SSOの設定が完了したので、作成したユーザーでログインしてみます。 ログイン用のURLはAWS SSOのTopにも表示されています。
ユーザー名、パスワードを入力すると以下のようにMFAを設定する画面が表示されます。 指紋認証も可能な「組み込みの認証アプリ」を使用しようとしたのですが、私のPCが対応してないようだったので、今回は認証アプリを使用します。
※スマホでログイン画面を見た場合は、指紋認証も設定できそうでした。
認証アプリでQRコードを読み取って、表示された番号を入力して設定します。
なお、私だけ、たまたまなのかもしれないですが、初回は以下のようにエラーとなりました。 再度ログインURLにアクセスすることでログインできました。
ログインが完了すると、以下のようにアクセス可能なAWSアカウントが一覧で表示されます。 system01アカウントのマネジメントコンソールへアクセスします。
ログインできました。
AWS SSOの設定は以上です。
AWS SSOのポイント
利用方法が理解できたところで、あらためてAWS SSOのポイントです。
認証・認可の管理を一ヵ所で行える
これが一番大きなポイントかと思います。MFAの強制もAWS SSO1ヵ所で設定してすべてのSSOユーザーに有効にできるのはとても良いですね。
CLIが使用できる
本記事の手順では紹介しませんでしたが、マネジメントコンソールへ入るときに、「Command Line or …」を選択すると一時的なアクセスキーを発行できます。 より安全な形でキーの発行、CLIの利用が可能になります。
AWS以外のアプリも使用できる
AWSアカウントへのログインをメインとしてAWS SSOがよく利用されますが、他のアプリへのログインも可能です。随時使用できるアプリは増えているようです。設定はSSO＞アプリケーションから可能です。
AWS SSOをIDのベースにして他アプリへのログインといった管理もできますね
外部IDプロバイダとの連携も可能
設定手順の最初にも書きましたが、外部IDとの連携機能も嬉しいですね。たとえば普段の業務ではActive Directoryの認証を使用している場合、その認証でAWSへログインするといった運用も可能です。
さいごに
本記事ではマルチアカウントのセキュリティサービス紹介の第一弾としてAWS SSOをメインに紹介しました。
認証・認可のところはAWSの使用開始にも必要であり非常に重要な部分でありますので、できるだけ早く検討、設定することをおススメします。
次回はコスト管理のサービスをまとめていきたいと思います。
AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法 ～はじめに～
AWSのセキュリティサービス、活用できていますでしょうか。
私も過去に以下のような発表を行ったり、
以下のような記事を書いております。
記載内容は、AWSアカウントは作成した時点でリスクを持つので、最低限有効化すべきサービスを有効にして、セキュアな状態を保ちましょうというものになります。
ただし、この内容はあくまでAWSアカウントを1つ作成するときの内容となっています。最近では開発、本番など環境に応じて複数のアカウントで1システムを運用することも多くなってきていると思います。
そこで複数アカウントの場合はAWSのセキュリティサービスをどう使用できるのか書いていきたいと思います。 すべてのサービスを1記事で書くと長くなるので、連載形式で順々に書いていこうと思います。
今回は「はじめに」ということでマルチアカウント管理の要である、Organizationsの機能についてざっと整理します。
AWS Organizationsとは
Organizationsは、複数のAWSアカウントを管理して、各種サービスをアカウント間で連携できる機能を持つサービスです。いくつかポイントを紹介します。
一括請求ができる
通常（Organizationsを使用しないで）AWSを利用する場合は、AWSアカウントごとにクレジットカード情報を登録し、アカウント単位で請求が発生します。
AWSにはコストを可視化できるCost Exploerなどコスト管理のサービスがいくつかありますが、これらのサービスもアカウント単位で利用することになるため、システム全体としてコストを管理していく場合に難しくなります。また、アカウントの追加ごとにカード情報を入力する必要があるため、手間もかかりますし、セキュリティ面でもカード情報が多く登録されることは好ましくないかと思います。
Organizationsを使用すると、請求およびコストの管理をマネジメントアカウントという全アカウントの親にあたるアカウントで一元管理が可能になります。
マネジメントアカウント上でシステム全体、またアカウントごとのコスト管理も可能になり、請求情報も1ヵ所で管理できるようになります。
他のAWSサービスを組織単位で使用できる
Organizationsで作成したAWSアカウントの集まりを組織と呼びますが、組織単位（＝全アカウント）でまとめてAWSサービスの設定が行えます。 使用できるサービスは限られますが、例えばAWSの操作履歴を残すCloudTrailの証跡設定では、組織単位でCloudTrailの証跡を有効にすることで、全アカウントの操作履歴を1つのアカウントで見れるようになります。
管理アカウントの委任
複数のアカウントに分ける場合、役割ごとにアカウントを分けるのが一般的であり、AWSもそれをベストプラクティスとする場合が多いです。役割ごとに分ける＝1アカウントに1つの役割を持たせるということになります。
Organizationsのマネジメントアカウントは請求管理の役割を持つので、セキュリティ情報の集約は別途セキュリティアカウントを用意してそこに集める構成を取ることも多いです。ただし、組織単位でサービスを使用すると、デフォルトではマネジメントアカウントに情報が集約されます。たとえばAWSの設定情報履歴を保存する AWS Configでは、CloudTrailのときと同様デフォルトでマネジメントアカウントに情報が集約されます。
この情報集約の役割を別アカウントに移せるのがアカウントの委任機能です。 委任が使用できるサービスは限られますが、アカウント委任を使用してセキュリティ集約アカウントに情報を集めることができます。
OU(Organizational Unit)とSCP(Service Control Policy)
OrganizationsにはOUという機能があり、組織内のアカウントをOUという単位でグループ化することができます。たとえば以下のように複数のシステムアカウントをまとめて一つのOU、セキュリティアカウントは別のOUという形でグループ化しておくことができます。
このOUと組み合わせて使用できる強力なセキュリティ機能がSCPです。SCPは複数アカウント（OU単位）に設定できるIAMポリシーのような機能で、「指定したOUに所属するアカウントではアクセスキーの作成を禁止する」といったセキュリティガードレールの設定も可能です。OUとSCPの具体的な設定方法については、以前私が発表した資料に書いておりますので、合わせてみていただけると幸いです。
そのほか指定のOUに所属するアカウント全てにCloudFormation（StackSets）を実行するといった、別サービスとの連携機能も一部あります。
AWS SSOとの連携
AWS SSO はOrganizationsと組み合わせて使用できるシングルサインオンのサービスです。1箇所で利用者の認証・認可の管理ができます。 こちらはOrganizationsの機能というよりは別のサービスになりますので、次回以降の記事で解説していこうと思います。
各セキュリティサービスの利用方法
Organizationsの機能をざっくり整理できたところで、これを活用して各セキュリティサービスがどう利用できるのか、以下のポイントで見ていきたいと思います。
- サービス有効化、マルチアカウントでの集約手順
- 組織単位で利用可能か
- アカウントの委任は可能か
見ていくサービスは以下のとおりです。各サービスの詳細は次回以降の記事で順々に書いていこうと思います。
- ルートユーザの保護、IAMの管理（AWS SSO）
- コストの可視化（Cost Explorer、Budgets）
- CloudTrail
- AWS Config
- Amazon GuardDuty
- IAM Access Analyzer
- AWS Security Hub
- Amazon Detective
- AWS Personal Health Dashboard
- AWS Trusted Advisor
各サービスの記事ができたら、この記事にもリンクを貼っていく予定です。 ひととおり書けたら、まとめと、CloudFormationでコード化するところも書いてみたいと思います。
マイペースで進めますので、完成は未定です・・1月上旬くらいには・・
re:Invent2020セッションレポート ：(DOP309) Test twice, deploy once: Testing infrastructure code on AWS
概要
インフラコードのテストに関するセッションです。タイトルの「Test twice, deploy once」は、英語のことわざ（？）である「measure twice and cut once」（2回測って、1回切る＝慎重に）から来ているようです。どのように正確に、インフラをテストできるのか。といった観点ですね。
AWSさんのセッションなので、AWS標準のツールであるCloudFormationとCDKを使用する場合の話になります。（TerraformなどAWS外のIaCツールについての説明はありません）
セッション内容
Why infrastructure as code?
背景
- 昔はオンプレミスのサーバー数百台にそれぞれJavaなどのソフトウェアをインストールしていた。時間がかかる
- 2000年代前半にIaCという言葉が出てきてブームになってきた
- 現代ではインフラはコード前提で考えるべき。クリックではなくLovelyなインフラのコードを
なぜIaCなのか？
- 再利用可能で、何がデプロイされるのか予測できる
- 共通のツールで変更リリースをコード変更として実行できる、テストもできる
- 本番やステージングなど、環境のコピーがしやすい
Testing AWS CloudFormation
コードには何をするか？
- テストをする、アプリケーションと同様
- 本番環境にリリース前にテストを実行しておきたい
CloudFormationの概要
- テストはどこから始めれば良いか
- cfn-nag
- rubyのgemパッケージ
- セキュアでないコードを見つけて警告を出してくれる
- cfn-lint
- linter
- コードの静的解析ツールで、文法チェックを行ってくれる
- リージョン単位でサポートしていないEC2などのケイパビリティも含めてチェックしてくれる
- TaskCat
- 実際にテンプレートをデプロイしてテストできるツール
- 複数のパラメータ入力に対応
- 設定したパラメータで、実際にテンプレートがデプロイできるかチェックできる
- デプロイが正常に完了したら、リソースは削除される
Testing AWS Cloud Development Kit (AWS CDK)
- なぜCDKなのか？
- CDKをどうテストしていくか
- jest というツールを使用してテストができる
- Snapshot tests、Fine-grained assertions、Validation tests３種のテストができる
- Snapshots
- CDKでデプロイした状況をSnapshotとして状態保存しておき、変更がされたら検知ができる
- 一度CDK経由でデプロイして、リソースの変更が行われると、テストがfailとなる
- テストがfailした場合はスナップショットを更新して対応する
- fine-grained assertions
- Snapshotsではできなかった機能単位の細かなテストを実施したい
- fine-grained assertionsを使用して実行できる
- 例えばメッセージ保持期間がXXXのSQSリソースがあるかチェックするいった書き方ができる
- チェックする内容から書くテスト駆動開発な進め方もできる
- SQSキューの保持期間が誤っていると以下のようにエラーになる
- validation tests
- 時間がないので資料なし、説明でさらっと
- 値の最小、最大といった少し複雑な書き方ができる。
Pipeline
IaCもアプリ同様にパイプラインにいれましょう
GitリポジトリにIaCテンプレートをコミット
- Buildフェーズではテストに必要なパッケージを用意してlintやnagといったコード解析テストを実行
- CDKの場合はjestを使用
- Testフェーズではどこかの環境にデプロイを行い、Lambda等を使用して環境チェックを行うテストを実行する
- テストが正常終了したらProduction環境へリリース
- CloudFormationの場合は以下のようなパイプライン構成となる
CDK Pipelines デモ
※デモ見たいかたはこちらのセッション動画をご覧ください（28:50頃～）
↓デモより一部説明を抜粋↓
- CDK Pipelinesはマルチリージョン、マルチアカウントにパイプラインの整備ができる
- パイプラインリソースとアプリケーションリソース（デモではLambda＋API GW）をCDKの中で管理
- stageという概念を使って、同じAWSリソースを複製できる
- cdk deployコマンドでパイプラインをデプロイできる
- test用のステージおよび処理もCDKの中に書ける（CurlコマンドによるURLチェックなど）
- デモで使ったコードは以下Githubにある
GitHub - darko-mesaros/cdk-pipelines
Homework
- 宿題（まとめ）
- インフラコードに色々なツールを入れて書き方デバッグ、テストをしてみよう
- インフラをCI/CDしよう
- 素晴らしいセキュアなインフラコードを書くことを楽しもう
感想
今やっている私がやっている業務にドンピシャな内容でした。現在はCloudFormationをメインにIaCの管理を行っていますが、パラメータを全て書くというところにツラさを感じているところです。パラメータの可読性は高くて良いのですが。
また、パイプラインも合わせてCloudFormationで作っているのですが、パイプラインの数も多くなりここも中々ツラくなってきているところです。CDK Pipelinesはパイプラインの整備や管理に大いに役立ちそうです。できるところから、CDKも試していきたいと思います。
IaCのテストにフォーカスしたセッションは過去に見たことがなく、悩んでいるところでもあったのでとても有益なセッションでした。インフラもテスト駆動で開発していきたいですね。
