お疲れ様です。矢儀 @yuki_ink です。
AWS Managed Microsoft AD、使ってますか？？
AWS Managed Microsoft ADは、AWS上で独自ドメインを管理したいとなったときに非常に便利なサービスです。
しかし、いざ作成しても、そのまま使い始めると躓いてしまうポイントがいくつかあります。
特に、いろんな制約のあるエンタープライズでは！
ということで、今回はそんな躓きポイントで躓かないために、AWS Managed Microsoft ADを作成したあとにまずやるべき設定をまとめます。
今書いているもの以外にも、思いついたら加筆していきます！
「これも最初にやるべき」という設定があれば、コメントいただければ幸いです！
AWS Managed Microsoft ADを作成し、ステータスがアクティブになったところから始めます！
今回はマネコンぽちぽちで作りました。
- 自動生成されたセキュリティグループの修正
- モニタリング・ログ転送設定の有効化
- 未使用のネットワーク暗号・プロトコル暗号の無効化
- AD管理サーバの構築
- パスワードポリシーの設定
- ドメインユーザ作成
- 条件付きフォワーダーの設定
- LDAPS通信の有効化
1. 自動生成されたセキュリティグループの修正
以下のようなケースで、セキュリティグループの修正が必要です。
- VPC外のリソースからAWS Managed Microsoft ADを利用したい場合（信頼関係や条件付きフォワーダーの設定など）
- 社内のセキュリティ要件を満たすため、必要最小限の通信許可しか設定したくない場合
【背景】
AWS Managed Microsoft ADの作成時に自動で作成され、ADのENIにアタッチされるセキュリティグループについて、初期状態では次のようなルールが設定されています。
必要に応じて、インバウンドルールを追加してあげる必要があります。
| ルール | 設定内容 |
|---|---|
| インバウンド | からの、AD関連通信を許可 |
| アウトバウンド | 全通信（0.0.0.0/0への全てのトラフィック）を許可 (※) |
※ 少し前までは、アウトバウンドルールは「同一のセキュリティグループに対してのみ、全てのトラフィックを許可」というルールになっていました。
条件付きフォワーダの設定や他ADとの信頼関係の構築の際に、ハマる要素の1つとなっていたのですが、最近改善されたようです。
（参考）AWS Managed Microsoft AD と オンプレAD で信頼関係を構築する (2020年5月版)
セキュリティグループの修正にあたっては、現時点では、自動生成されたセキュリティグループを手動で修正するしか方法がありません。
ADに紐づくENIから「セキュリティグループを変更」をクリックし、他のセキュリティグループをアタッチできるか確認しましたが、現時点では You do not have permission to access the specified resource. と表示され、エラーとなってしまいます。
抵抗があるかと思いますが、もともとアタッチされているセキュリティグループのルールを、手動で修正しましょう。。
2. モニタリング・ログ転送設定の有効化
「モニタリングしてればよかった…」「監査ログ消失してる…」となる前に！！
インシデントが発生してから悔やんでも遅いのです。
【背景】
AWS Managed Microsoft ADのモニタリング設定とログ転送設定は、現時点のデフォルトでは無効化されています。
特に本番環境で利用する場合は、設定を入れておいたほうがいいと思います。
2.1. モニタリング
ADのステータスが Active (アクティブ) から Impaired (障害) または Inoperable (操作不能) に変わると、SNSトピックに通知されるように設定できます。
ADが復旧し、Active (アクティブ) に戻ったときにも通知を受け取れるので便利です。
ディレクトリ詳細ページの メンテナンス タブ > ディレクトリのモニタリング から設定します。
詳細な手順は公式ドキュメントを参照してください。
2.2. ログ転送
アカウントログオンやオブジェクトアクセス、ポリシー変更といった項目のログを取得できます。
取得できるログの種類は公式ドキュメントを参照してください。
ディレクトリ詳細ページの ネットワークとセキュリティ タブ > ログ転送 から設定します。
詳細な手順は公式ドキュメントを参照してください。
3. 未使用のネットワーク暗号・プロトコル暗号の無効化
利用しないプロトコル・暗号方式が分かっているのであれば、最初から無効化しておきましょう。
【背景】
AWS Managed Microsoft ADが対応しているプロトコル・暗号方式については、デフォルトでは全て有効化されています。
後から設定を変えるとなると、影響調査など手間がかかるので、構築時点で利用しないことが分かり切っているものがあるのであれば、最初に無効化しておくことをおすすめします。
ディレクトリ詳細ページの ネットワークとセキュリティ タブ > ディレクトリ設定 から設定します。
詳細な手順は公式ドキュメントを参照してください。
4. AD管理サーバの構築
以上でマネジメントコンソールでの操作は終わり、いよいよADの中身の設定に入っていきます。
その前提として、AD管理サーバを構築しておきましょう。
以下の記事が参考になります。
5. パスワードポリシーの設定
自社のセキュリティ要件に沿うように、最初にパスワードポリシーを仕込んでおきましょう。
【背景】
現時点で、デフォルトでは以下のポリシーが設定されていますが、企業のセキュリティ要件に完全にフィットするものではないと思います。
企業内のシステムの一部としてADを使うのであれば、そのポリシーはセキュリティ要件に合致させておきましょう。
後から設定を変えるとなると、影響調査など手間がかかるので、最初にやっておくことをおすすめします。
私からは、以下の設計をおすすめします。
- のパスワードポリシーは「きめ細かいパスワードポリシー（PSO）」で制御
- のパスワードポリシーは「グループポリシー（GPO）」で制御
パスワードポリシーだけなら「きめ細かいパスワードポリシー（PSO）」で制御するに越したことはないのですが、、
ドメインに参加しているコンピュータ（特にドメイン管理用のコンピュータ）に対しては、セキュリティの観点から、リモートアクセスを拒否する設定を入れることが推奨されています。
そしてそれを設定できるのは「グループポリシー（GPO）」となっているため、コンピュータの制御という意味では「グループポリシー（GPO）」に寄せたほうがよいと考えます。
ドメインおよびエンタープライズ管理者のネットワーク権限またはドメインに参加しているコンピュータアカウントへのリモートアクセス権限を拒否するグループポリシーオブジェクト (GPO) を作成します。
詳細については、セキュリティポリシー設定に関する Microsoft のドキュメント「ローカルでのログオンの拒否」および「リモートデスクトップサービスによるログオンの拒否」を参照してください。
5.1. きめ細かいパスワードポリシー（PSO）の設定
以下の記事が参考になります。
5.2. グループポリシー（GPO）の設定
以下の記事が参考になります。
パスワードポリシーの設定に加え、必要に応じて「ローカルでのログオンの拒否」と「リモートデスクトップサービスによるログオンの拒否」も設定しておきます。
6. ドメインユーザ作成
デフォルトで作成される Admin ユーザは、初期構築後は使わないようにします。
パスワードをランダム文字列にしておいて、あとは放置しておきましょう。
パスワードはマネジメントコンソールからいつでも変えられるので、必要に迫られたらその時にまたパスワードを変更すればいいと思います。
各 AWS Managed Microsoft AD デプロイには、ディレクトリを管理するためにプロビジョニングされた Active Directory アカウントがあります。このアカウントの名前は Admin です。
ディレクトリをデプロイしたら、ディレクトリにアクセスする必要がある昇格されたユーザーごとに個別の Active Directory ユーザーアカウントを作成することをお勧めします。
これらのアカウントを作成したら、管理者のアカウント認証情報をランダムなパスワードに設定し、ブレークグラスシナリオ用に保存することをお勧めします。
管理者アカウントなどの共有アカウントや汎用アカウントを標準管理に使用しないでください。そうしないと、ディレクトリの監査が困難になります。
というわけで、普段使い用のドメインユーザを作成します。
詳細な手順は公式ドキュメントを参照してください。
前述の項目で設定したパスワードポリシーが適用されるよう、また、適切な権限が割り当てられるように、グループの設定などは忘れずに行いましょう！！
ユーザの権限設計については、自社のセキュリティ要件に沿ってくださいとしか言えないのですが、、突き詰めると、役割に応じた最小権限が原則です。
考え方としては、以下のMicrosoftの記事が参考になると思います。
7. 条件付きフォワーダーの設定
AWS Managed Microsoft ADには、デフォルトでAmazon Provided DNS (Amazon Route 53 Resolver) へのフォワーダー設定が入っています。
これにより、AWS Managed Microsoft ADのDNSで解決することができない名前解決のリクエストはAmazon Provided DNSに転送され、VPC内部のDNS名 (例：ip-xx-xx-xx-xx.ap-northeast-1.compute.internal) や、インターネット上のDNS名 (例：www.google.co.jp) の名前解決が可能になります。
しかし、オンプレミス環境で独自ドメインをホストしている場合などはAmazon Provided DNSでも名前解決ができないため、別途条件付きフォワーダーを設定してあげる必要があります。
（参考）
今回作成したAWS Managed Microsoft AD以外にも、独自ドメインを管理しているドメコンがあるのであれば、条件付きフォワーダーを設定する必要があります。
注意事項を含め、以下の記事が参考になります。
レプリケート設定は「このドメインのすべてのDNSサーバー」を必ず選択するようにしましょう。
8. LDAPS通信の有効化
追加構築レベルの話なので、「AWS Managed Microsoft AD作成時に最初にやるべき設定」に入れるのは少々気が引けますが…
LDAPS通信が必要なことが分かっているのであれば、初期構築時にまとめてやっておいたほうがいいかな、というレベルです。
以下の記事を参考にしてください。
ここまでお目通しいただき、ありがとうございました。
書き始めると結構やることが多くて驚きましたw
【再掲】
今書いているもの以外にも、思いついたら加筆していきます！
「これも最初にやるべき」という設定があれば、コメントいただければ幸いです！
最後に、上記で紹介できなかったものの、参考にさせていただいた記事を紹介させていただきます。
ありがとうございました。
Views: 0
