Active Directory資産を活用したAWS Management ConsoleへのSSO

2015年08月23日
藤本真司（0）
19

はじめに

藤本です。

みなさん、AWS Management Consoleのアカウント管理はどうされていますか？
AWSにおけるアカウント管理は多数存在し、その中でもManagement Consoleへのログインに関するアカウント管理も多数存在し、何を選択するのがベストなのか判断が難しいところです。
今回はWindows ServerのActive Directoryと連携し、Management Consoleへシングルサインオンする方式をご紹介します。

この方式を利用することで得られるメリットは多くあります。

【利用者】

新たなアカウントを管理する必要がない
Active Directoryのアカウントのみを管理していればよく、新たなアカウントID、パスワードを管理する必要がない。

【管理者】

既存のActive Directory資産を利用可能
既に社内でActive Directoryによってアカウント管理されている企業はアカウント情報をそのまま利用できます。
IAMユーザーの個別管理不要
認証をActive Direcotryに委任することでManagement Consoleのアカウント管理から開放されます。社員入社時のアカウント追加、部署異動時の権限変更、社員退職時アカウント削除を全てActive Directoryだけで行うことができます。
グループによる権限管理でもアカウントの特定が可能
現在のアカウント管理は「誰が」、「いつ」、「何に対して」、「何を」行ったのか、トレースできる仕組みを導入することが一般的です。複数人で一つのアカウントを使い回すのではなく、個別アカウントの管理が必要です。上記のグループによる個別管理不要の仕組みを考える場合、「誰が」を追うことができなくなりがちです。AWSでトレースの仕組みとしてCloudTrailがありますが、今回ご紹介する方式はADアカウントの任意の情報をAWSに渡すことによりアカウントを特定したトレースを行うができます。ここは「動作確認」の章で説明します。
アカウント乗っ取りの回避
イントラネット内のActive Directoryに認証することで、誰でもアクセス可能なパブリッククラウドのリスクでもあるユーザーID・パスワード漏洩によるアカウントの乗っ取りのリスクも回避することができます。
既存環境の設定変更が最小限（ADアカウントへのグループ追加のみ）
今回ご紹介する方法は既存Active Direcotryの設定をほぼ変更することなく、実現可能なため導入のリスクが限りなく少ないです。ADFSはAcitive Directoryと同居させても問題ないですが、Active Directoryへの変更リスクを考慮すると、新規で立てる方がよいように思えます。サーバ購入手配の方がハードルが高いようでしたら同居を選ぶこともありかと思います。

いかがでしょうか？
アカウント管理者、セキュリティ担当者は導入を考えたくなるのではないでしょうか？

概要

この方式はオンプレミスのActive Direcotry Federation Services 2.0（以下、ADFS）をSAMLのIdentity Provider（以下、IdP）として導入し、AWSとSAML認証することでSSOを実現します。Active Directoryのアカウント情報からIAM RoleへAssumeRoleすることでAWS Management Consoleの権限を得ることができます。

今回の設定例ではActive Directoryのアカウントが属するグループ名とIAM Roleをマッピングしています。
例えば、AというADアカウントを「AWS-developer」グループに所属させることでIAM Roleの「ADFS-devoloper」としてログインすることができます。

この方式は公式ドキュメントが大変わかり易いので、ご参照いただければと思います。
SAML を使用してフェデレーティッドユーザーに AWS コンソールへのアクセスを許可する

設定の流れは以下となります。

ADFSインストール
ADFS初期設定
ADFSメタデータ取得
AWSへIdP登録（SAML2.0認証用）
IAM Role作成（AssumeRoleWithSAML）
ADFS信頼関係追加
ADFS要求規則設定
（必要に応じて）ADアカウントへのグループ割り当て

環境

接続元 : オンプレミス(自宅)

AD
OS : Windows Server 2012R2
ミドルウェア : Active Directory ドメインサービス、DNSサーバー
ADドメイン : fujimoto-home
利用するADアカウント : sfujimoto (所属グループ : AWS-developer、メールアドレス : sfujimoto@fujimoto-home.local)
ADFS
OS : Windows Server 2012R2
ミドルウェア : Active Directory Federation Services
Client
OS : Windows 7

やってみた

Active Directoryは導入済みとします。

ADFS2.0インストール
サーバーマネージャの役割と機能のインストールからActive Directory Federation Servicesを選択するだけなので、今回は手順を省略します。
　
ADFS初期設定
ADFSの初期設定を行います。　
- 初期構成ウィザード
  インストール後にサーバーマネージャのタスクにて構成を促されますので、こちらを開きます。　
  　
- ようこそ
  Active Directoryフェデレーションサービス構成ウィザードが開きます。
  　
- AD DSへの接続
  ドメインアカウント情報を入力し、利用するAD DSを指定します。
  
  　
- サービスのプロパティの指定
  SSL証明書の登録、フェデレーションサービス名の指定を行います。
  今回、SSL証明書はIISにおいて発行した自己署名証明書を利用しています。
  フェデレーションサービス名はログインページで表示されます。
  
  　
- サービスアカウントの指定
  ADFSがADとやり取りするサービスアカウントを指定します。
  今回はAdministratorアカウントを利用していますが、本番環境では最小限の権限に絞ることが望ましいです。
  
  　
- データベースの指定
  ADFSで利用するデータベースを指定します。
  今回はデータベースを準備していないため、新規作成します。
  
  　
- オプションの確認、前提条件の確認
  そのまま次へ進めます。
  
  　
ADFSメタデータ取得
構成したADFSからSAML用Metadata（XMLファイル）をダウンロードします。
　
- Webブラウザから以下のURLへアクセスします。
  https://＜ADFSのURL＞/FederationMetadata/2007-06/FederationMetadata.xml
  
  　
- IEでアクセスした場合、互換表示設定し、表示されたXMLを保存します。
  
  　
AWSへIdP登録
ダウンロードしたADFSメタデータをAWSへ登録し、SAML認証可能な状態へと設定します。
　
- IdP作成ウィザード
  IAMを操作する権限があるアカウントでAWS Management Consoleへログインします。
  IAM IDプロバイダ設定画面へ遷移し、プロバイダの作成を選択します。
  
  　
- プロバイダの設定
  プロバイダの設定項目を入力します。
  プロバイダーのタイプ : SAML
  プロバイダ名 : （任意の名前）
  メタデータドキュメント : ダウンロードしたXMLファイル
  
  　
- プロバイダー情報の検証
  設定内容を確認して、作成を選択します。
  
  　
- 設定確認
  作成されたIDプロバイダを選択して、プロバイダのARNを控えておきます。
  このARNにAPIを発行することでセッショントークンを発行します。
  
  　
IAM Role作成
ログインアカウントに付与したい権限のRoleを作成します。
今回の設定例ではADアカウントが所属するグループ名で付与するIAM Roleをマッピングします。ADグループ「AWS-XXXX」とIAM Role「ADFS-XXXX」がマッピングする命名規則で設定します。環境で記載したグループとマッピングしたいため、「ADFS-developer」を作成します。
IAMのロール設定画面へ遷移し、新しいロール名の設定を選択します。
　
- ロール名の設定
  ロール名 : ADFS-developer
  
  　
- ロールタイプの選択
  今回はSAMLによるシングルサインオンを実施するため、「SAML プロバイダへのウェブシングルサインオン（WebSSO）アクセスを付与」を選択します。
  
  　
- 信頼性の確立
  よく分からない日本語になっていますが、「するには」に作成したIDプロバイダを選択します。
  するには : fujimoto-home
  
  　
- ポリシー設定
  そのまま次のステップにいきます。
  
  　
- ポリシーのアタッチ
  割り当てたい権限を選択します。
  
  　
- 確認
  設定内容を確認します。
  
  　
ADFS信頼関係追加
ADFSの設定に戻って、ADFSがAWSに認証するための設定をします。
サーバーマネージャの[ツール]から[AD FSの管理]を開きます。

　
- 証明書利用者信頼を追加します。
  
  　
- データソースの選択
  オンラインまたはローカルネットワークで公開されている証明書利用者についてのデータをインポートする : チェック
  フェデレーションメタデータのアドレス : https://signin.aws.amazon.com/static/saml-metadata.xml
  
  　
- 表示名の指定
  任意の名前を指定します。（以下のキャプチャはデフォルトです）
  
  　
- あとはデフォルトのままウィザードを進めます。
  
  　
ADFS要求規則設定
AWSへの信頼関係を追加すると、要求規則の設定画面が表示されます。

　
「規則の追加」を選択し、要求規則を追加します。
今回、追加する要求規則は4つとなります。
　
- Windows アカウント名 -> 名前ID
  要求規則テンプレート : 入力方向の要求を変換
  入力方向の要求の種類 : Windows アカウント名
  出力方向の要求の種類 : 名前 ID
  出力方向の名前IDの形式 : 永続 ID
  
  　
- Emailアドレスの送信
  要求規則テンプレート : LDAP属性を要求として送信
  属性ストア : Active Directory
  LDAP属性 : E-Mail-Address
  出力方向の要求の種類 : ：https://aws.amazon.com/SAML/Attributes/RoleSessionName
  
  　
- ADアカウントのグループ取得
  要求規則テンプレート : カスタム規則を使用して要求を送信
  カスタム規則 :
```
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => add(store = "Active Directory", types = ("http://temp/variable"), query = ";tokenGroups;{0}", param = c.Value);
```
  　
- グループ名をIAM Role名とマッピングするように変換
  要求規則テンプレート : カスタム規則を使用して要求を送信
  カスタム規則 :
```
c:[Type == "http://temp/variable", Value =~ "(?i)^AWS-"] => issue(Type = "https://aws.amazon.com/SAML/Attributes/Role", Value = RegExReplace(c.Value, "AWS-", "arn:aws:iam::000000000000:saml-provider/ADFS,arn:aws:iam::00000000000:role/ADFS-"));
```
  ARNが２つあります。1つ目のARNはIDプロバイダのARN、2つ目のARNはIAM RoleのARNの途中までとなります。
  これにより、グループ名からIAM Roleをマッピングすることができます。
  
  　
  4つの要求規則が作成されました。

以上で設定完了です。

動作確認

それでは動作確認しましょう。動作確認環境は別途Windows7のクライアント端末から実施します。デフォルトのADFSの認証ページとなるURLへWebブラウザからアクセスします。
https://＜ADFSのURL＞/adfs/ls/IdpInitiatedSignOn.aspx
それでは追加した証明書利用者信頼で設定した名前を選択して、サインインします。

ドメインアカウント情報を入力して、サインインします。
「sfujimoto」アカウントは「AWS-developer」グループに所属するアカウントです。

Management Consoleが表示されましたね！
AWSのアカウント情報を入力することなく、シングルサインオンできました。

ログイン情報を確認していただくと分かる通り、AssumeRoleで得た権限のIAM RoleとADアカウントに設定したメールアドレスが表示されています。このメールアドレスによって個人を特定することができます。
この情報がCloudTrailに残ることで「はじめに」で挙げた行動のトレースが可能となります。

# aws s3 cp s3://cloudtrail-ap-northeast-1-0000000000/AWSLogs/0000000000/CloudTrail/ap-northeast-1/2015/08/22/00000000000_CloudTrail_ap-northeast-1_20150822T0635Z_78Oo0xg79lwdo9qa.json.gz - |gunzip -d |jq '.'
{
  "Records": [
（略）
    {
      "eventVersion": "1.03",
      "userIdentity": {
        "type": "AssumedRole",
        "principalId": "**************:sfujimoto@fujimoto-home.local",
        "arn": "arn:aws:sts::00000000000:assumed-role/ADFS-developer/sfujimoto@fujimoto-home.local",
        "accountId": "00000000000",
        "accessKeyId": "******************",
        "sessionContext": {
          "attributes": {
            "mfaAuthenticated": "false",
            "creationDate": "2015-08-22T06:29:57Z"
          },
          "sessionIssuer": {
            "type": "Role",
            "principalId": "*******************",
            "arn": "arn:aws:iam::00000000000:role/ADFS-developer",
            "accountId": "00000000000",
            "userName": "ADFS-developer"
          }
        }
      },
      "eventTime": "2015-08-22T06:32:49Z",
      "eventSource": "monitoring.amazonaws.com",
      "eventName": "DescribeAlarms",
      "awsRegion": "ap-northeast-1",
      "sourceIPAddress": "***.***.***.***",
      "userAgent": "console.amazonaws.com",
      "requestParameters": {
        "maxRecords": 100
      },
      "responseElements": null,
      "requestID": "9bfb57a8-4897-11e5-b579-ad52ef2b6541",
      "eventID": "aca02423-c8a5-4a88-a62b-8cf0d4ca062a",
      "eventType": "AwsApiCall",
      "recipientAccountId": "*********"
    }
  ]
}

userIdentityのprincipalIdにメールアドレスが記録されています。

まとめ

いかがでしたでしょうか？
設定も(要求規則を除いて)シンプルで分かりやすいのではないでしょうか。
私自身、Active Directoryの管理者をしたこともなく、構築もしたことがないレベルでも、ある程度の仕組みを理解し、設定することができました。
また今回の使い方以外にも外部からのAPIの認証や、Directory Serviceとの連携等でもActive Directory資産をAWSで活用することができます。これらはまた別のエントリで紹介させていただきます。

参考サイト

Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0
ADFSを利用してAWSにシングルサインオンする方法

絞り込むカテゴリーを選択