Ch4. 組織の複雑さに対応する設計

AWS SAP対策

AWSアカウントを跨いだリソースアクセス

別のAWSアカウントで実行されているアプリケーションに対して、自分のAWSアカウントのリソースへのアクセスを実現したい場合、IAMロールによる権限の委任(Assume Role)を利用することが出来る。

Assume Roleとは

IAM ロールにより、お客様の信頼するアカウントと他の信頼される AWS アカウントとの信頼関係を確立できます。
IAM ユーザーにアクセス権限を委任するロールの作成 - AWS Identity and Access Management

とある。

このIAMロールを設定するにあたり注意しなくてはならないのが、外部IDの設定である。

ユーザーが属する他のアカウントが管理対象外の AWS アカウントである場合は、externalId 属性を使用することもできます。外部 ID は、お客様とサードパーティーのアカウントの管理者との間で同意した任意の単語または数値です。このオプションにより、リクエストに正しい sts:ExternalID が含まれている場合にのみユーザーがロールを引き受けることができるという条件が、信頼ポリシーに自動的に追加されます。

このIAMロールに対して作成されるIAMポリシーには2つの種類のポリシーが存在する。

  1. アクセス許可ポリシー(自分のアカウントのAというリソースに対するRead/Writeの許可)
  2. 信頼ポリシー(誰がこのロールを引き受けることが出来るか)

AWS リソースへのアクセス権を第三者に付与するときに外部 ID を使用する方法 - AWS Identity and Access Management

2.の信頼ポリシーには

  • Princpal
  • Condition

の2つが指定できるので、Principalに外部のAWSアカウントを指定・Conditionに外部IDを指定する。外部IDが一致しないと、このロールを引き受けることが出来ないのでロールの引き受けに対するPWとして機能させる_ことが出来る。

こうして作成されたAWSロールは、当然AWSアカウントを跨いで共有される必要があるため、ARN(Amazon Resource Name)という一意な名前を名付けられ、外部アカウントの管理者に対して共有する。

Amazon リソースネーム (ARN) - AWS 全般のリファレンス

外部IDについては、下記のような制約があるため生成は外部アカウントの管理者に依頼する必要がある。

2 つの顧客に同じ値を使用することはできません。Example Corp は、顧客ごとに ExternalId 値を指定する必要があります。重要なことは、生成元が顧客ではなく、Example Corp である点です。

AWS リソースへのアクセス権を第三者に付与するときに外部 ID を使用する方法 - AWS Identity and Access Management

ユーザー認証の種類

AWSへのリソースアクセスを可能とするためのユーザー認証技術には下記のようなものがある。

  • OAth 2.0
  • SAML 2.0
  • Assume Role with Web Identity

OAuth2.0

そもそもOAuthの本来の役割とは、[認可(≒承認)]であり、各リソースへのアクセスの許可/拒否を制御するためのものである。

自分の作成したWebサービスにGoogleやAmazonが提供するOAuthサービスを利用したくなるのは、「ユーザーを一意に識別する認証機能の実装を省き、どのユーザーが何をするかだけコントロール(≒認可)したい」と考えているからだ。実際、エンドユーザがOAuthを利用する際は、GoogleやAmazonのログイン画面に遷移して認証を受ける。

OAuthは認証機能のアウトソーシングのための仕組みであり、またそれを提供するのはGoogleやAmazon、Facebookと言ったパブリックプロバイダである。自社で実装する仕組みではない。

https://www.cloudflare.com/ja-jp/learning/access-management/what-is-oauth/

SAML2.0

SAMLは認証のための仕組みであり、SSOでは「認証した結果、一意にしたユーザーの属性を他のシステムに送信する」のに利用される。

SAMLで認証された結果得られる、ユーザーの属性情報をアサーションと呼ぶ。 AWSのマネジメントコンソール等でSSOを実現するには、このアサーションをユーザー側からポストさせる必要がある。SAMLとはSecurity Assertion Markup Languageの略であり、このアサーションの記述に用いられる模様。

Security Assertion Markup Language - Wikipedia

オンプレミスのActive Directoryに認証情報が存在した場合、認証後にアサーションを発行させた後それをAWS側での認証に用いることが出来る。このアサーションの発行機関をIdp(IDプロバイダ)と呼び、Active Directoryと連携する場合はActive Directory Federation Service(ADFS)等を用いる。

ADFSはOffice365やWindows Serverとの連携も可能で、連携元の認証を元にアサーションを発行できる（なお、ActiveDirectory自体がMicrosoftのサービス）。

Active Directory Federation Services - Wikipedia

AWS側ではIAMを元にSAMLプロバイダを作成する。SAMLプロバイダはアサーションを元にIAMユーザーを識別し、一時的なサインイン用トークンを発行する。アサーションによって許可されたユーザーに対するIAMロールは事前に作成しておくことが求められる。この時の信頼ポリシーにはこのSAMLプロバイダを指定する。

各端末はこのトークンを受け取ったのち、AWSのコンソールログイン画面へとリダイレクトされ、そのトークンを元にログインが出来る。

Assume Role With Web Identity

先ほどのSAMLの例ではIdpとしてADFSが用いられた。この他にもFacebookやAmazonなどのソーシャルログインをIdpとして利用し、AWSへのログインを許可する方法。

ネット上には日本語の情報が少なく、アサーションに代わるものをどのように連携するのかについては現在も調査中。

AWSアカウントを跨いだリソースへのアクセス2

AWSアカウントを跨いだリソースへのアクセスを許可する場合、

  1. 自分のアカウントのリソースへのアクセスを許可したIAMロールを外部のアカウントに引き受けさせる。

  2. 自分のアカウントのリソースにアクセスを許可する(外部のアカウントの)ユーザーを指定する。

の2パターンの方法が存在する。

1.の方法は既に確認したが、その際は「こちらが発行したIAMロールを別のアカウントのアプリケーションに委任する」という使い方をした(ロールによる権限委任)。勿論このIAMロールをユーザが引き受けることも可能である。但し、このロールを引き受けたユーザーはこのロールで許可された内容しかアクセスを維持できない。

これはロールを引き受けるのがアプリケーションであれば問題ないことが多いものの、ユーザーであれば自分のアカウントのリソースへのアクセスと言った基本的な操作すら維持できなくなるため、問題が大きい。

IAM ロールとリソースベースのポリシーとの相違点 - AWS Identity and Access Management

プリンシパルは信頼されたアカウントのリソースに引き続きアクセス可能である一方で、信頼するアカウントのリソースにもアクセスできます。これは、他のアカウントに属する共有リソースから、また共有リソースへと情報をコピーするといったタスクにおいて便利です。

リソースベースポリシーは、リソースに対して直接アクセス可能なユーザーを指定するという点で、IAMロールによるアイデンティティベースポリシーとは完全に切り離された別物である。

アイデンティティベースのポリシーおよびリソースベースのポリシー - AWS Identity and Access Management

今回のようなユースケースでは、「別ユーザーが別アカウントでの作業用の アイデンティティベースポリシーによるロールを引き受けつつ、更に自アカウントの特定のリソースへのアクセスも可能」としなくてはならない。この場合、自アカウントへのアクセスはリソースベースポリシーに直接指定する方法が考えられる。

Direct Connect

(確認中)

VPNからDirect Connectへの移行

VPNからDirect Connectへのマイグレーションを円滑に行うには、BGPのルーティングテーブルにおける優先度を設定しDirectConnectの優先度を高く設定する。

VPNでは接続の両端に下記のエンドポイントが必要になる

AWS Site-to-Site VPN の仕組み - AWS Site-to-Site VPN

一方、DirectConnectでは下記のエンドポイントが必要になる。

  • Customer Router 　
  • AWS Direct Connect Endpoint
  • Virtual Private Gateway

※DirectConnectにCustomer Gatewayは必要ないことに注意。混同しやすい。

AWS Direct Connect とは - AWS Direct Connect

Virtual Private GatewayはDirectConnectの接続を最優先にルーティング決定するため、AWS→オンプレミスの接続に関してはDirectConnectを用意した時点でマイグレーションに関する作業が必要ない。

Site-to-Site VPN のルーティングオプション - AWS Site-to-Site VPN

一方、オンプレミス→AWSの接続に関しては、オンプレミス側のルータ(Customer Router/Gateway)の優先度を変更することでフェイルオーバーしつつ、安全なマイグレーションが行える。

DirectConnectのルーティングテーブル伝搬

先述したように、DirectConnectでは下記3つのエンドポイントがある。

  • Customer Router 　
  • AWS Direct Connect Endpoint
  • Virtual Private Gateway

VPC内のインスタンスからDirectConnect経由でオンプレミスにルーティングするには、VPC内のルーティングテーブルにCutstomer Router向きのルートが存在することが必要になる。これは手動設定が必要になる。

(表1. VPCのルーティングテーブル)

Destination NextHop
Cutomer Network Virtual Private Gateway

更にCustomer NetworkからVirtual Private Gateway経由でVPC内のインスタンスへのルーティングが実施されるには、Virtual Private GatewayへのルートがCustomer Routerに存在する必要もある。

Direct Connect プライベート仮想インターフェイスのルーティングを設定する

(表2. Customer Gatewayのルーティングテーブル)

Destination NextHop
VPC Subnet AWS Direct Connect Endpoint

このルーティングを把握するには、Customer Gatewayのルータに手動設定を行う、またはVirtual Private Gatewayからルート情報が伝搬されている必要がある。この設定を明示的に実施する必要があるのかどうかはよくわからない。

ルーティングポリシーと BGP コミュニティ - AWS Direct Connect

Systems Managerに出来ること

Guard DutyとCloud Trail