こんにちは、AWS サポート課（旧テクニカルサポート課）の坂本（@t_sakam）です。今回も、前回に続いて AWS Systems Manager (SSM) の新しいエクスペリエンスについてのブログです。
はじめに
今回、前回は未確認であった Systems Manager の新しいエクスペリエンスの発表ページで紹介されている、以下の内容（AWS Organizations 利用、アンマネージドノードの診断と修正）を確認するために、検証を始めました。
今回のリリースにより、組織の AWS アカウントとリージョンにあるすべてのマネージドノードとアンマネージドノードを 1 か所で確認できるようになりました。アンマネージドノードを特定、診断、修正することもできます。
引用元 : AWS Systems Manager の新しいエクスペリエンス: ノード管理の簡素化 - AWS
設定⾃体は非常に簡単で、数クリックで完了しました。しかし、その裏では、複数の AWS のサービスが「委任された管理者」や「信頼されたアクセス」として自動的に設定され、IAM ロールをはじめとするさまざまなリソースが作成されていることが確認できました。
そのため、実際に利用する前に裏側の仕組みも理解しておいたほうが良さそうです。そこで本シリーズでは、今回から数回にわたって、Systems Manager の新しいエクスペリエンスの内部構成について検証していきます。
今回は初回のため、表側での設定手順が中心になりますが「委任された管理者（Delegated Administrator）」や「信頼されたアクセス（Trusted Access）」についての説明も、途中でおこなっていきたいと思います。
- AWS Organizations を利用した組織全体への有効化
- AWS Organizations を利用した場合の構成
- 有効化の設定手順（管理アカウント側）
- 「委任された管理者」と「信頼されたアクセス」
- 有効化の設定手順（委任された管理者アカウント側）
- 管理アカウント側で再度確認
- まとめ
AWS Organizations を利用した組織全体への有効化
今回は、導入編として、AWS Organizations を利用した組織全体への Systems Manager の新しいエクスペリエンスの有効化が完了するところまでを主に表側から確認します。
下の構成図で言うと、左側の管理アカウント (Org) で設定を開始し、中央のメンバーアカウント (Ops) が「委任された管理者」として登録され、新しいエクスペリエンスの有効化を完了するところまでが今回の範囲です。
AWS Organizations を利用した場合の構成
検証に利用したアカウントの構成
今回の検証には、以下の構成図のような 4 つのアカウントが必要です。
AWS Organizations を利用した環境では、アカウントは大きく分けて「管理アカウント」と「メンバーアカウント」の 2 種類に分類されます。今回の Systems Manager の新しいエクスペリエンスは、前回確認したような単一のアカウント環境でも利用可能です。一方で、マルチアカウント・マルチリージョン環境を一括で管理したい場合は、AWS Organizations を利用した環境が必要になります。
また、今回の Systems Manager の新しいエクスペリエンスの有効化をおこなう際、管理アカウントを管理者として設定することはできません。メンバーアカウントの一つを、Systems Manager をはじめとするいくつかのサービスの「委任された管理者」として設定する必要があります。
これは、AWS Organizations を利用した環境の場合のベストプラクティス（すべての管理を管理アカウントでおこなうのではなく、必要な役割によって、管理を委任して運用しましょう）に沿って、そういった仕様が採用されていると考えられます。
また、組織全体を操作するために「委任された管理者」と合わせて、必要なサービスについて「信頼されたアクセス」も有効にする必要がありますが、今回検証したところ「委任された管理者」や「信頼されたアクセス」は、新しいエクスペリエンスを有効化するだけで、自動的に設定される仕様となっていました。
アカウントの詳細
| アカウント | 説明 |
|---|---|
| 管理アカウント (Org): | AWS Organizations 環境における「管理アカウント」。 |
| メンバーアカウント (Ops): | 後の手順で「委任された管理者」になるアカウント。「委任された管理者」とは、特定のサービスの管理を、管理アカウントではなく、他のメンバーアカウントに任せるための仕組み。 |
| メンバーアカウント (Prod): | 本番環境をイメージしたアカウント。マルチリージョン対応を確認するために、今後のブログで、us-west-2 リージョンに EC2 を設置。 |
| メンバーアカウント (Dev): | 開発環境をイメージしたアカウント。マルチリージョン対応を確認するために、今後のブログで、ap-northeast-1 リージョンに EC2 を設置。 |
有効化の設定手順（管理アカウント側）
管理アカウント [Org] の Systems Manager の Top 画面中央の［使用開始］ボタンを押すか、左メニューの［設定］をクリックします。
「委任された管理者」として設定したいアカウントの アカウント ID を入力ボックスに入力し［確認］ボタンを押します。
下の画面内で、Systems Manager を組織レベルで利用するためには、関連するいくつかのサービスに対して「委任された管理者」と「信頼されたアクセス」を設定する必要がある、と記載されていますが、このまま［確認］ボタンを押すだけで、必要なサービスに関してはすべて自動で設定されます。
ただ、管理アカウント側だけでは、設定は完了しません。下の画面は［確認］ボタンを押したあとの画面です。この段階では、まだ「委任された管理者」アカウントの設定は完全には完了していません。
画面には「委任された管理者なし」の注意メッセージが表示されています。引き続き、先ほど「委任された管理者」として設定した、メンバーアカウントの [Ops] 側でも設定をおこなう必要があります。
「委任された管理者」と「信頼されたアクセス」
委任された管理者（Delegated Administrator）
特定の AWS のサービスの管理を、組織内の特定のメンバーアカウントに任せる設定のことです。
AWS Organizations では、管理アカウントが組織全体の管理を担っていますが「委任された管理者」にメンバーアカウントを設定すると、設定をした特定のサービスについては、「委任された管理者」アカウントが管理アカウントに近い権限で、組織内のリソースの操作をおこなえるようになります。
AWS のベストプラクティスでは、管理アカウントは、組織の構造管理やポリシー統制（SCP の設定）等の管理アカウントでしかおこなえない作業に限定して使用することが推奨されています。
それ以外の日常的な作業は、役割に応じてメンバーアカウントを「委任された管理者」として設定し、適切に分担することで運用の安全性とスコープの明確化を図ることができます。
管理アカウントは、管理アカウントが必要なタスクにのみ使用してください
管理アカウントとそのユーザーおよびロールは、そのアカウントで実行する必要のあるタスクのみに使用することをおすすめします。すべての AWS リソースを組織内の他の AWS アカウントに保存し、管理アカウントから遠ざけます。リソースを他のアカウントで保持する重要な理由の一つは、管理アカウントのユーザーとロールに対する制限に Organizations サービスコントロールポリシー (SCP) を使用できないためです。
引用元: 管理アカウントのベストプラクティス - AWS Organizations
設定されたかどうかをマネジメントコンソールで確認するためには、「委任された管理者」アカウント側のそれぞれのサービス画面側で確認をする必要があります。
もしくは、AWS CLI で以下のコマンドを実行することで、特定のアカウントがどのサービスの「委任された管理者」として設定されているかを確認することができます。
aws organizations list-delegated-services-for-account --account-id <[Ops] アカウントのアカウントID>
信頼されたアクセス（Trusted Access）
「信頼されたアクセス」とは、特定の AWS のサービスが AWS Organizations の組織情報にアクセスできるようにする仕組みです。
有効化することで、そのサービスは組織内の複数のアカウントやリージョンを対象に、横断的な操作やリソースの展開を実行できるようになります。
今回は「委任された管理者」と「信頼されたアクセス」の両方が自動で設定されましたが、多くのサービスでは、「委任された管理者」を登録するために、事前に信頼されたアクセスを有効にすることが前提となっています。
アカウントをあるサービスの委任管理者として登録する前に:
そのサービスが委任管理者をサポートしていることを確認します。どのサービスが委任管理者をサポートしているかについては、AWS のサービス で使用できる AWS Organizations の表を参照してください。 そのサービスでの信頼されたアクセスを有効にします。
引用元 : Organizations と連携 AWS のサービス する の委任管理者 - AWS Organizations
上の画面は、管理アカウント [Org] の Organizations の「サービス」の画面です。この画面で、信頼されたアクセスが有効になっているサービスを確認することができます。
今回は、新しいエクスペリエンスの有効化時に、自動で以下の 4 つのサービスが「信頼されたアクセス」として有効化されました。
- AWS Resource Explorer
- CloudFormation StackSets
- Quick Setup（Systems Manager の一機能）
- Systems Manager
AWS CLI で「信頼されたアクセス」が有効になっているサービスを確認するには、以下のコマンドを実行します。
aws organizations list-aws-service-access-for-organization
有効化の設定手順（委任された管理者アカウント側）
次は、「委任された管理者」として設定した、メンバーアカウント [Ops] 側で設定をおこないます。Systems Manager の Top 画面中央の［使用開始］ボタンを押すか、左メニューの［設定］をクリックします。
次の「Systems Manager を有効にする」画面で［編集］ボタンを押します。
続けて「組織の設定」画面が表示されます。ap-northeast-1 リージョンを選択して操作しているので、「ホームリージョン」は ap-northeast-1 になります。
ap-northeast-1 リージョンは、他のアカウントやリージョンからの情報をまとめて収集する「集約元」として機能し、Systems Manager の新しいエクスペリエンスにおける、組織全体の統合コンソールの操作の起点になります。
「アカウント」に関しては、現時点では選べないようです。管理対象は、管理アカウント以外の組織全体のアカウントが対象となります。管理アカウントが対象外となっているのは、前述した AWS のベストプラクティスで推奨されている「管理アカウントにリソースは置かない」という前提があるためかと思われます。
「リージョン」項目では、対象リージョンを選択することが可能です。今回は、アカウントだけでなく、リージョンも複数ある環境で動作確認をおこないたいため、us-west-2 と ap-northeast-1 の 2 つを選びます。（ap-northeast-1 はホームリージョンであるため、デフォルトで選択されており、チェックを外すことはできません。）
画面右下の［送信］ボタンを押してしばらく待つと「委任された管理者」アカウントの設定が完了します。主にこの設定を待つ間に裏側で自動処理が走り、IAM ロールをはじめとする多数のリソースが作成されます。
管理アカウント側で再度確認
管理アカウントで操作できないことを確かめるために、管理アカウント [Org] の方で Systems Manager の「ノードのインサイトを確認」画面を確認します。「委任された管理者」アカウントを確認するようにとのメッセージが表示されており、管理アカウントではこの画面は操作できず、「委任された管理者」アカウントでの操作が必要であることがわかります。
引き続き、管理アカウント [Org] の「設定」画面を再度確認すると、今度は「委任された管理者なし」の注意メッセージが消え、設定が完了していることを確認できます。
まとめ
今回は、AWS Systems Manager の新しいエクスペリエンスを AWS Organizations を利用した環境で、組織全体に対して有効化する設定をおこないました。
また、この有効化で設定される「委任された管理者」と「信頼されたアクセス」についても確認しました。
有効化の作業自体は数クリックで済み、とても簡単ですが、これは Systems Manager の 一機能である Quick Setup によって実現されています。
そのため、次回は、Quick Setup によって自動的に構成される IAM ロール等のリソースを取り上げ、流れを確認します。
