AWS Directory Service(Simple AD)のみでユーザ管理(AWS Management Console編)

西澤です。システムを運用していると、ユーザ管理はなかなかコストのかかるお仕事です。AWSから提供されているアカウント管理サービスがせっかくありますので、AWS Directory ServiceのSimple ADに集約して、アカウント管理ができないか考えてみようと思います。

目標

IAMユーザを使わずに、Simple ADで管理できるアカウントのみで、AWSを運用してみることを目標にやってみます。システム管理者がなるべくコストをかけずにアカウント統制できることが理想です。

• 人間が操作するアカウントを、IAMユーザを使わず、ADアカウントのみで管理する
• ユーザができることはなるべくユーザにしてもらう
• パスワードポリシー等の一般的なセキュリティ要件を満たせるかも確認する

環境

AWS Directory ServiceはADライクなSamba 4 Active Directory Compatible Serverを管理してくれるだけなので、アカウント操作用のインターフェースは用意されていません。アカウント管理はWindows環境にRSAT(Remote Server Administration Tools)等を用意して操作を行います。AWS Directory Serviceで用意したSimple ADに参加できる環境さえ整えればAWS環境外からの管理も不可能ではありませんが、今回はAWS内にWindowsサーバを用意してSimple ADのアカウント管理を行う方針としました。

Simple ADの作成

Simple ADの作成は非常に簡単です。AWS Management Consoleからポチポチと作成してしまいましょう。

Windows環境の準備

今回はAWS上にWindows Server 2012 R2を用意し、アカウント管理用環境としましたが、ドメイン管理者でログインしてRSATが使える環境であれば、ここではバージョンはあまり重要では無いはずです。

※再現性が確認できないのですが、Windows Server 2012 R2環境からAD DSツールを介してAWS Directory Serviceに接続した際に、一部操作が原因不明のエラーとなることがありました。Simple ADのバージョンは、6.1(Windows Server 2008 R2相当)と認識されているので、もう少し近いバージョンで組み合わせておいた方が無難かもしれません。

• AMI: Windows_Server-2012-R2_RTM-Japanese-64Bit-Base-2015.08.12

下記の機能を追加して、AD上のアカウントやポリシーを管理します。

• グループポリシーの管理
• リモートサーバ管理ツール
  • 役割管理ツール
    • AD DSおよびAD LDSツール

WindowsのSimple ADへの参加手順については、下記記事をご覧ください。この辺りは予定しているこの記事の続編でも取り扱う予定です。

• AWS Directory ServiceでActive Directoryを立ててWindowsを参加させる

アカウント作成

用意したWindows環境から、AD上に下記のセキュリティグループとアカウントを用意しました。

• セキュリティグループ: AdPowerUsers
  • ユーザ: bob
• セキュリティグループ: AdReadOnlyUsers
  • ユーザ: jane

管理ツール→Active Directory ユーザーとコンピューターから作成していきましょう。後で必要となりますので、必ず電子メールも登録しておくようにしましょう。

AWS Management Consoleへのアクセス許可

AD上に作成したセキュリティグループをIAMロールにマッピングさせて管理しようと思います。まずは、AccessURLを有効にしておきます。

AWS Management Consoleへのログイン権限を付与する設定を下記のようにマッピングします。グループで管理しておけば、ユーザの追加・削除の対応はAD側に行うだけで済むはずです。IAMロールの作成も、AWS Manegement Consoleから誘導してくれるので、設定する権限だけ注意をすれば簡単に設定できると思います。

本物のADと連携するパターン(AD Connector)となりますが、AWS Management Consoleへのアクセスを許可する為に必要となる操作方法は下記記事と同じです。

• Active Directoryを活用したAWS Management ConsoleへのSSO（AD Connector編）

IAMロールとAD上のセキュリティグループのマッピング設計を最初に行っておけば、あとはAWS Management Consoleからのアカウント管理は不要となります。この例では、AD上でAdPowerUsersグループに追加されたユーザ(bob)はPowerUser権限、AdReadOnlyUsersグループに追加されたユーザ(jane)はReadOnly権限でAWS上のリソースにアクセスることができるようになりました。

アカウント運用

ここからが本題となるのですが、この方式で運用した場合、何ができて何ができないのかを色々と調べてみました。

アカウントの改廃

AD上のセキュリティグループとIAMロールをマッピングして運用することができますですので、個人アカウントの改廃はAD上のユーザ作成/削除(セキュリティグループへの追加/削除)のみで対応ができそうです。アカウント管理を集約できていると言えると思います。

パスワードの管理

パスワードの管理はユーザでやってもらいたいです。先に設定したメールアドレスを利用したパスワードリセット用の機能が実装されているので、これでシステム管理者の手をわずらわせずにユーザ自身がパスワードを変更することができます。ADアカウントのパスワードリセット用の画面を実装しようとすると大変なので、これはありがたい機能です。

登録済みのメールアドレスに下記のようなメールが届くので、リンクをクリックするとパスワードを変更することができます。画像にある通り、一定以上の強度が強制される仕様となっているようです。

Dear User,

We have received a request to reset a user account associated with this email address. If you submitted this request, please visit the following URL to reset your password:

Reset Password ※ここがリンクになっている

Your password will not be reset unless you confirm this email address using this URL. This link expires an hour after your original request.

If you did not request to reset this password, do not click this link. Instead, please forward this notification to aws-directoryservice@amazon.com to let us know that you did not request the password reset.

Thanks, The AWS Directory Service Team

パスワードのリセットが成功すれば、確認のメールも届きます。

Dear User,

The password of your account has been successfully changed.

If you did not request this password change, please contact your Administrator immediately.

Thanks, The AWS Directory Service Team

パスワードポリシー

ユーザのパスワードをリセットしたり、グループポリシーエディターからパスワードポリシーを色々といじってみたのですが、Simple ADでは、できることとできないことがあるようです。この点については検証ベースですので、決して動作を保証するものではありません。ご了承ください。また、今回の環境はSimple ADですので、AD Connectorを利用して検証してみると結果が変わると思います。

• 制御できたこと
  • パスワードの長さ(パスワードリセット画面上では8文字以上の記載だが、ポリシーからより多い文字数指定で制限可能)
  • パスワードの有効期限の管理(有効期限が切れると認証エラーとなった、事前通知機能等は存在しない)
• 制御できなかったこと
  • 初回ログイン時にパスワード変更要求(認証エラーになった)
  • パスワードの変更禁止期間の指定(パスワードリセット機能からの変更は無視された)
  • パスワード履歴の記録により再利用の禁止(パスワードリセット機能からの変更は無視された)
  • ログイン試行によるアカウントロックアウト(何度ログインに失敗してもロックアウトはしなかった)

初回ログイン時のパスワード変更要求やパスワードの有効期間切れ等は全て認証エラーとなったのですが、そこで気付いたユーザにパスワードリセットをしてもらえば運用上は問題は無さそうです。パスワードの再利用禁止が使えるとより望ましかったのですが、検証した結果ではポリシーから指定しておいても、パスワードリセット機能から同一のパスワードを設定することができてしまいました。

ポリシー設定をしてもアカウントがロックアウトすることはありませんでしたが、一定回数以上パスワードを間違えるとログイン画面が下記のように遷移しました。

画像認証が追加されていますので、ブルートフォースアタック対策にはなりそうです。ここではアカウントロックアウトは無くてもよしとしておきましょう。

アクセスキーを使いたい(課題)

AWSリソースにアクセスする場合には、アクセスキー/シークレットアクセスキーが必要となる場面がありますが、今回の方式ではユーザにアクセスキーを利用してもらう為の手段が見つかっていません。Simple ADの認証を使って一時クレデンシャルを呼び出すような方式が取れると良いのですが。

まとめ

アカウント管理を集約したい、ということで、AWS Directory ServiceでAWS Management Consoleへのアクセス権限をどこまで管理できるか考えてみました。当然ですが、せっかくADアカウントが使えるのですから、AWS Management Consoleへのログイン管理だけしても不十分です。1本の記事ではまとめきれなさそうなので、続編として次回は、OSへのログインを全てSimple ADを利用して管理する方法を考えてみようと思っています。