LoginSignup
2
1
@Kept1994

AWSマネコンへのSSOとかSTSの一時認証とかまとめ

Last updated at Posted at 2023-11-05

社内リソースのSSO

AWS云々の前にそもそも社内のリソースへのアクセスを一元化するにはどうするのか。

Active Directory

システム管理者が組織のリソースを管理するマイクロソフト製のサービス。
社内にはファイルサーバやプリンタなど様々なサーバやデバイスがあり、それぞれがユーザ認証を必要としている。各デバイスを利用する度にユーザ名とパスワードを求められ、各デバイスでそれらの認証情報を保持するのは効率がいいとは言えない。また管理者側からするとそれらの権限管理をバラバラに設定していくことは煩雑でオペミスを誘発する原因にもなりうる。
そこで、それら認証や権限管理を一箇所に集約することで、ユーザへはシングルサインオン(SSO)を提供し、管理者へは管理の一元化を提供する方法が出てきた。Active Directoryはその一つである。

ディレクトリ

Active Directoryは組織のリソース(人や物、データなど）をオブジェクトとしてツリー構造で表現したディレクトリを用いて管理している。各オブジェクトの情報(ユーザ名や所属などの付帯情報)はプロパティ(属性)として紐づけられている。このディレクトリの情報の保管と検索を行うプロトコルとしてLDAPを用いる。

なお、これはファイルを束ねるフォルダをディレクトリと呼ぶのと同じである。ファイルという個々のリソースをディレクトリがツリー状に管理している。

ディレクトリによって各ユーザの所属や利用できる権限が一括で管理でき、これはディレクトリデータベースとしてドメインコントローラがその役割を担っている。

ドメインとドメインコントローラ

ディレクトリによって管理されるリソースの範囲をドメインと呼び、ドメインを管理するサーバのことをドメインコントローラと呼ぶ。ドメインコントローラはディレクトリの情報に基づき認証・認可を行うサーバともなる。

社内のサーバやデバイスはこのドメインコントローラを信頼することでドメインに参加できる。これはドメインコントローラが代わりに認証・認可したユーザのアクセスを受け入れることになるため。

ドメインコントローラの役割として以下の役割を有する。

  • ディレクトリデータベース
  • 認証と認可
  • グループポリシー

信頼関係

ドメインは、ディレクトリによって管理されるリソースの範囲であるが、組織構造(親会社子会社の関係)や企業合併によって複数のドメインに分かれることが想定される。
ドメインは別のドメインに対して信頼関係を構築することでによってドメイン間で連携することができる。
上位組織と下位組織(サブドメイン)の間で信頼関係を結び構築された構成をドメインツリーと呼び、別のドメイン間の信頼関係をフォレストと呼ぶ。

ユーザからの社内リソースへのアクセスの流れ

image.png

  1. ユーザから認証サーバ(ドメインコントローラ)にアクセスし、認証される。
    → 「この人は誰か」を証明できた状態。
  2. 認証サーバからTGT(Ticket Granting Ticket)というチケットが返却される。
  3. ユーザはそれを持って認可サーバ(ドメインコントローラ)にアクセスし、認可される。
    → 「この人がどの権限を持っている」が証明された状態。
  4. 認可サーバはST(Service Ticket)というチケットを返却する。
  5. STによって権限が保証されているサーバやデバイスにそれを提示することでアクセスできるようになる。

この認証の流れをKerberos認証というプロトコルと呼ぶ。

AWSへのSSO

SAML2.0

社内のリソースへの認証が一元管理され、SSOすることができるようになったが、外部のサービス(AWSのマネジメントコンソールなど)に対するアクセスも一元管理したくなる。
ここで利用されるのがSAML2.0などのプロトコルを用いるSSOである。

SAML2.0ではIDプロバイダ(IdP)を間に立てることでSaaSへのアクセスを橋渡ししている。
ドメインコントローラから受け取るSTをIdPが受け取り、トークンを発行する。
このトークンをSaaSに提示することで既に認証されたユーザと認識できる。さらに事前にIdP側のユーザ/グループとSaaS側の権限と紐づけておくことでSaaS上での権限も制御できる。

image.png

Service Provider(SP)

SAML認証でユーザがログインするアプリケーションのこと。IdPからユーザの認証情報を受け取りユーザをアプリケーションにログインさせる。

ID Provider(IdP)

SAMLにおいてIdPはユーザ情報を管理し認証を行うサーバ。IdPでログインしたユーザ情報をSPへ提供する。

SAML認証の流れ

image.png

マネジメントコンソールへのアクセスフロー (SP initiated SSO)

image.png

  1. IdPの提供するポータルURLへアクセスする。
  2. IdPはIDストアに対してユーザ認証を実施する。
  3. IdPがSAMLアサーションを発行する。
  4. ユーザのブラウザからAWS(ServiceProvider)のSSOエンドポイントにリダイレクトされアサーションを送る。
  5. エンドポイントはAssumeRoleWithSAMLAPIをコールしてSTSから一時的な認証情報を取得しサインインURLを生成する。
  6. サインインURLへリダイレクトする。

※ IdP initiated SSO と SP initiated SSOは以下。ユーザアクセスがどっちが先かの話。

IdPとIDストアの選択

この流れにおいてIDストア側とIdP側に何を選択するかにはいろいろな種類がある。
すでに組織が利用しているIDストアがあるなどで制約が変わってくるが、AWS SSO(現AWS IAMアイデンティティセンター)で一元的に管理できる。(以前はAWS SSOはOrganizationsのマスタアカウントでしか設定でいなかったが今ではできるらしい)

image.png

image.png

IDストア、IdPの選択のフローチャート

AWS SSO (現AWS IAM アイデンティティセンター)

オンプレミスとのSAML認証認証連携によるSSOとMFA認証が可能となる。
オンプレや外部IDストアと連携するしてAWSマネコンやAWSサービス(QuickSightやWorkSpaces)へのシングルサインオンを実現する。
CognitoのユーザプールでAWS SSOをIdPに指定することも可能。

まとまった絵があるので以下を参考に。

AWS Directory Service

image.png

AWS Managed
Microsoft AD

Microsoft Active Directoryをマネージドに提供しているサービスであり、裏側では実際にWindows Serverが起動しActive Directoryが動いている。2AZにまたがって構成され、管理を行うには別途EC2インスタンスに管理ツールを導入して管理を行う(?)。

既存のオンプレミスADと連携させたい場合(既存のADに登録しているユーザでAWSマネコンやQuickSight、WorkSpacesなどへログインしたい場合)、信頼関係を構築することで可能となる。

マネコンへのSSOの流れ

  1. AWS Managed
Microsoft ADリソースを作成時に発行するアプリケーションアクセスURLにアクセスするとサインイン画面にアクセスできる。
  2. AWS Managed
Microsoft AD上のユーザもしくは信頼関係を結んだオンプレADのユーザでログインする。
  3. ログインに成功すると、あらかじめ紐づけたIAMロールで有効にしたAWSアプリケーション(マネコンなど）にアクセスできる。

Simple AD

Microsoft ADと互換性のあるSambaを使ったスタンドアロンのマネージド型ディレクトリサービス。
Managed Microsoft ADと同様2つのサブネットが必要。

AD Connector

オンプレミスAD等既存のActive Directoryへの接続を仲介するサービス。一部のAWSサービスはAWS Directory Serviceとのみ連携可能であるためオンプレADとの連携にAD Connectorを利用する。

STS(AWS IAM)

上記のSSOとはまた別で、アプリケーションからAWSリソースにアクセスする際の一時停な認証を与える方法。

image.png

image.png

基本的に多くのケースでCognitoの利用が推奨される。
結局はAssumeRoleWithWebIdentity APIがコールされているので自前実装することで1から構築することは可能。

GetxxxToken系はIAMユーザをベースとしているのに対し、AssumexxxRoleはIAMロールベース。

GetFederationToken

組織でSAML2.0非互換のIDストアを利用している場合、SAML2.0の動作を模倣したカスタムIDブローカーを噛ます構成をとる。IDブローカーからSTSに対してGetFederationToken APIコールすることで一時的な認証情報が返却される。

AssumeRoleWithSAML

SAML2.0互換のIdPを有している場合に利用できる。

AssumeRoleWithWebIdentity

OIDC互換のパブリックなWebベースのIdP(GoogleやFacebookなど)を使用する場合、およびCognitoにプールされたユーザを使用する場合に利用できる。

GetSessionToken

信頼されない環境からIAMユーザでアクセスする時に利用。
MFAを利用して一時的な認証情報(アクセスキー、シークレットキー、セキュリティトークン)を取得する際に利用。

AssumeRole

IAMユーザで付与されてないポリシー権限でAWSリソースにアクセスさせる時に利用。
なお、GetFederationTokenやGetSessionTokenはいずれもAssumeRoleで代用可能らしい(?未理解)

参考

Microsoft AD

AWSへのSSO

AWS Directory Service

AWS Managed
Microsoft AD

STS、IDフェデレーション

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
1