アクセス管理

01

誰なのか、何をしてよいのか：認証と認可

会社のビルに入るときを考えてみましょう。入口では社員証で本人かどうかを確認し、各フロアでは、その社員証で入れる場所かどうかをもう一度確認します。前者が認証（Authentication、誰なのかを確認すること）、後者が認可（Authorization、その人がこの操作をしてよいかを決めること）です。クラウドでも、まったく同じように2つの段階を通ります。

リクエストを送る側をセキュリティプリンシパル（principal）、略してプリンシパルと呼びます。プリンシパルは人だけではありません。毎晩バックアップを実行するプログラムや、注文を処理するサーバーも、クラウドのストレージやデータベースを呼び出すので、どちらもプリンシパルです。人にはパスワードと2つ目の確認手段を、プログラムにはキーや一時的な認証情報を渡して、誰なのかを示してもらいます（4章）。下の図で状況を切り替えてみましょう。

HTTPの標準では、401が認証失敗（誰なのかをもう一度示してください）、403が認可失敗（誰なのかはわかるが、許可しない）を意味します。ところが、クラウドのAPIはこの区別にそのまま従わないこともあります。どちらも403で返すところもあれば、どちらも401で返すところもあります。ここがつまずきやすいところです。ステータスコードよりも、エラーコードとメッセージを見て、どちらの扉で止まったのかを見分けましょう。

いちばん強いアカウントは、使わないアカウント

クラウドのアカウントを最初に作るときにできる最上位のアカウント（ルート・メインアカウント、最上位の管理者）は、何でもできます。決済情報の変更やアカウントの解約までできてしまいます。だからこのアカウントにはMFAをかけて金庫にしまっておき、普段の作業は権限を分けた別のアカウントで行います。このアカウントが乗っ取られたら、どんな権限設定も役に立たないからです。

誰なのかを確認する扉を見てきました。では、社員が使うアプリが何十個もあったら、その扉をアプリごとに別々に建てる必要があるのでしょうか？

02

IDを1つにまとめる：SSO・フェデレーション・MFA・条件付きアクセス

アプリごとにアカウントとパスワードを別々に持つと、パスワードが増え、みんな同じパスワードを使い回すようになります。退職者が出たら、アプリを1つずつ回ってアカウントを削除しなければならず、1つでも漏れると、その扉は開いたままになります。そこでIDはIDプロバイダー（IdP）の1か所にまとめます。サインインはIdPで1回だけ行い、アプリはIdPが発行した証明（トークン）を信頼して中に入れます。これがSSO（シングルサインオン）です。

会社がすでに社内ディレクトリを使っているなら、クラウドに人を新しく作らなくても、そのディレクトリを信頼させることができます。このように、ほかの組織による本人確認を信頼することをフェデレーションといい、その証明をやり取りする標準がSAML 2.0とOIDC（OpenID Connect）です。

パスワード1つでは足りない：MFA

パスワードは、フィッシングや、ほかのサイトから漏れたパスワードを通じて、簡単に漏れてしまいます。MFA（多要素認証）は、パスワードに加えて、持っているもの（スマートフォンのアプリ、セキュリティキー）や自分自身（指紋）で、もう一度確認します。ここがつまずきやすいところですが、同じMFAでも強さは違います。SMSや認証アプリの6桁の数字は、偽のサイトにそのまま入力させられて突破されることがありますが、セキュリティキーとパスキー（FIDO2）は本物のサイトでしか動かないので、フィッシングに強いのです。

状況を見て決める：条件付きアクセス

サインインのたびに、同じ強さで確認する必要はありません。会社のノートPCでオフィスから入るならそのまま通し、初めての国や端末から入ってきたらMFAを求めたり、ブロックしたりできます。このように、ユーザー・場所・端末・リスクといったシグナルを見て、「許可 / 追加の確認のうえで許可 / ブロック」を決めるのが条件付きアクセスです。IDが1か所（IdP）にまとまっていてこそ、こうした条件も1か所で設定できます。

誰なのかは、はっきりしました。次は2つ目の扉、「この操作をしてよいか」を決めるポリシーを読んでみましょう。

03

ポリシーの読み方：誰が・何を・どこに・どんな条件で

権限はポリシーで与えます。プロバイダーごとに見た目は違っても、ポリシーに入る項目はほとんど同じです。誰が（プリンシパル）、何を（アクション）、どこに（リソース）、どんな条件で（条件）、そして許可なのか拒否なのかです。

許可 | 誰が：開発者グループ
     | 何を：オブジェクトの読み取り、オブジェクトの書き込み
     | どこに：開発用バケットのすべてのオブジェクト
     | 条件：MFAでサインインしたときだけ

リクエストが来ると、システムはそのリクエストに当てはまるポリシーをすべて集めて照らし合わせます。判定のルールは3行だけです。

下の図で、許可ポリシーと拒否ポリシーを付けたり外したりしてみましょう。

ポリシーを付ける2つの場所：ID側とリソース側

ポリシーは、人・グループ・ロールといったIDに付けることもあれば（「この人は何ができる」）、ストレージのようなリソースに付けることもあります（「このバケットには誰が入れる」）。リソース側のポリシーには、必ず「誰が」の項目が入ります。リソース側のポリシーは、ほかのアカウントや組織のプリンシパルを受け入れるときに特に大事なので、5章でじっくり見ます。

一人ひとりにではなく、まとめて与える：グループとロール

ポリシーを一人ひとりに付けていると、人が増えるほど管理できなくなります。同じ仕事をする人をグループにまとめてグループに付けたり、「読み取り専用」「データベース運用者」のように権限のまとまりをロールとして作って与えたりすることを、ロールベースのアクセス制御（RBAC）といいます。さらに、タグのような属性を条件に使って、「プロジェクトのタグが同じリソースだけ」のように与えることを、属性ベースのアクセス制御（ABAC）といいます。

ポリシーは、人にだけ付けるものではありません。人がいない夜中もずっと動いているプログラムには、どうやって権限を与えるのでしょうか？