[レポート] 4次元の(より高度な)アクセス制御 – re:Invent 2019 #SEC405 #reinvent

アクセス制御のConditionについて深堀りして、より高いセキュリティや管理を目指す内容です。アクセス制御の濃い話が気になる方にお勧めのセッション。
2019.12.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

今回はre:Invent2019にて行われた下記セッションについてレポートします。

SEC405 - Access management in 4D -

In this session, we take "who can access what under which conditions" and deeply explore "under which conditions." We demonstrate patterns that allow you to implement advanced access-management workflows such as two-person rule, just-in-time privilege elevation, real-time adaptive permissions, and more using advanced combinations of AWS identity services, a range of environmental and contextual information sources, and automated and human-based approval workflows. We keep things fun, engaging, and practical using a lively mix of demos and code that you can take home and implement in your own environment.

[翻訳]

このセッションでは、「誰がどの条件の下で何にアクセスできるか」を取り上げ、「どの条件の下で」を深く探求します。 AWS IDサービスの高度な組み合わせ、さまざまな環境およびコンテキストの組み合わせを使用して、2人ルール、ジャストインタイムの権限昇格、リアルタイムの適応型アクセス許可などの高度なアクセス管理ワークフローを実装できるパターンを示します 情報ソース、自動化された人間ベースの承認ワークフロー。 デモとコードを活発に組み合わせて持ち帰り、自分の環境に実装することで、物事を楽しく、魅力的で、実用的に保ちます。

登壇者: Quint Van Deman Principal Business Development Manager - AWS Identity , Amazon Web Services

レポート

このセッションにおける4Dとはアクセス制御のPARCモデルの話。4次元目はCondition。粒度を改善するためにConditionを利用する。

物理では時間が4次元目。AWSにも時間でのアクセス制御を追加する。

なお、この講演はLevel 400(高難易度)なので初心者向けの説明はなくデモとコード祭りです。

前提として昨年のre:Invent 2018で行われた SEC401セッション Mastering Identity at Every Layer of the Cakeの続きです。

Layer Cakeとは各レイヤー毎のIdentityの管理があるという話。

今回はConditionについてフォーカスしていきます。

Grantsの設定とGuardrailsの設定は色々あるが、Grantは少なくとも1つ必要。

Part1: Out of the box

複数のポリシーを組み合わせて最小権限にしていく。まずはベーシックなIdentityベースのポリシーから。

ここにS3のリソースベースポリシーや、間にあるVPCエンドポイント、KMSのポリシーも付け足して最終的にはこんな感じ。

ちなみにVPCエンドポイントでは新サービスのOUを指定したCondition keyが活用されています。

[UPDATE] OU等のグループ単位でアクセス制御できる新しいCondition keyが発表されました! #reinvent

次は裏を返してポリシーを動的に変更して最小権限にする方法。

ロールベースアクセス制御だとリソースが増えたときにポリシーの変更が多くて大変になる。

そんなときは属性ベースアクセス制御(ABAC)にするとより楽に管理できるようになる。ユーザにもリソースにもタグをつける。

デモ: 4Dユーザーポータルを作っておいてCognitoと連携してRBACを実現。

やってみた。ID側のABACポリシーはシンプル。

サービス間のポリシー。もう少しインタラクティブにしたいので…

先程と同じように新機能のOUでCondition設定をすることによりスケールするように。

これでもいいが、動的にIdPからAttributeを受け取るための機能としてSession Tagをリリース。

機能の詳細はこちらのブログで。

[UPDATE]フェデレーションでタグを渡せるSTSの新機能Session Tagがリリースされました #reinvent

Session Tagを利用すると、動的なポリシーやロールを利用することが可能。

デモ: Session Tagを利用して指定したEC2にだけSession Managerでアクセスできるようにする

最小限のSession ManagerのポリシーをEC2にあてる。

ABAC側はSession Tagを受け取るためにタグの要素をConditionで指定。動いた。

Session TagはAuth0やonelogin等のIdPと連携できます。

リージョンについての制御はSCPで。

詳細はこちら。

続いて動的なAssume Roleについて。Assume Roleはポリシードキュメントを渡すことによりそのRoleより限定したアクセスが可能。これもカスタムブローカーで実装すればいい。

続いてリアルタイムに動いているEC2へのアクセス。これもカスタム。

一時的なアクセス許可の実装。

こんな感じ。

感想

非常に密度の濃い話でした。より厳密な管理が必要な場合には様々な実装が可能であることがよくわかりました。

このような実装に興味があれば、セッションの動画等をご確認ください!