次の方を対象にしています！
- 書籍「デジタルアイデンティティー」の内容が知りたい
- アイデンティテー管理（ID管理）を知りたい
- なぜアイデンティティー管理をする必要を知りたい
- アイデンティティー管理の自社ビジネスへの応用方法を知りたい
インターネットで買い物やコミュニーケーション、ゲームまで何でもできる時代です。
そして各サービスでは ID・パスワードを設定してはいるものの企業も個人も管理が大変になってきています。
より使いやすく、より安全に IDを管理するための方法を紹介します。
参考：すぐそこにあるサイバーセキュリティーの罠
ブログや本を読むのが面倒な方は、聞き流せるAudibleがオススメ！無料で体験できます！
>> 詳細はこちら
＼ 聞き流せる本！Audilbe無料体験期間中 ／
>> 詳しく知りたい方へ！Audibleで1冊無料でもらう方法を徹底解説
デジタルアイデンティティー要約｜GAFAの中心戦略「デジタルアイデンティティー」。まとめ。
GAFA とは Google、Apple、Facebook、Amazon の頭文字をとった言葉です。よく聞くようになりました。しかし、ビジネスの共通点は少ないです。
- Google：検索サービス、Gmail、Youtube、スマートフォン用のOS Androidの開発、Google Cloud Platformなど
- Apple：iPhone、iPad、Mac など
- Facebook：SNS
- Amazon：ECサイト、AWS など
このように似ていません。インターネット中心のサービスで、多数ユーザがいて、大規模なデータセンターを持っている点は共通しています。
さらに目を向けると「デジタルアイデンティティー」を中心に戦略を立てている、という共通点があります。
デジタルアイデンティティーとは「デジタル」と「アイデンティティー（属性の集合）」をつなげた言葉です。
アメリカの空港などで「ID を見せてください」と言われることがあります。この ID とは「アイデンティティーの文章（ドキュメント）」のことです。たとえばパスポートです。
パスポートでいえば氏名や生年月日、国籍などが書かれています。この属性をあつめたものが個人のアイデンティティーとなります。
このような実体に関する属性情報をデジタルで表現したものが「デジタルアイデンティティー」です。
WEB のさまざまなサービスで ID・パスワードのログインが求められます。サービスごとに ID・パスワードのアイデンティティーがあるのです。
しかし Google はどうでしょうか？ Gmail、Youtube、Goole Photo など一度ログインしてしまえばサービスをまたいで利用できます。
これが他の企業と GAFA の違いです。
アイデンティティー管理をする理由
- 貴重なリソースに対するアクセス制御。何かの情報を取得するときに「誰が」「いつ」「どこから」「なんのために」「なにを」「どのように」アクセスできるか決めるために情報システムではアイデンティティーを使って制御される
- 従業員や顧客の関係性の強化。従業員や顧客などの「人」はそれぞれ異なる。どのようなアイデンティティーの人がどのような情報を欲しているのか企業は分析している
- 生産性の向上。アプリケーション（サービス）毎にアイデンティティーを管理するのではなく、一箇所で集中管理することでシステム開発者は既にあるものを使えばよいため効率が上がる
Amazonのマイクロサービス化
Amazon は一つの大きなサービスだっため少し変更を加えるだけでも全体に影響してしまい、現状のシステムに限界を感じていました。
そこで Amazon をシステムを分割しました。
たとえば、ID管理・商品管理・倉庫管理のような分割です。お互いを連携するときは HTTPS の REST API という仕組みを使いました。
これによりシステム改善や修正するときは分割したサービス内だけが影響するため、影響範囲を小さくできました。これを「マイクロサービス化」といいます。
この方針に従わなかった社員はクビにすると宣言したそうです。
さらにチームは「Two-pizza teams」と呼ばる最大10人（2枚のピザを分けて食べれる程度の人数）としました。
この取り組みで ID管理システムが独立したのです。
ID管理システムがなければ「この注文はだれのか？」など分からなくなってしまうため重要なシステムといえます。
また ID管理システムが独立したことで、外部に ID管理システム（API）を公開できるようになります。
たとえば他の Twitterアカウントでログイン、Facebookアカウントでログインというのを見たことないでしょうか。
このように世の中には、ID管理システムが公開されていて他のサービス（たとえば自社サイト）で使えるようになっているのです。
アイデンティティー管理フレームワーク
よく使われるフレームワークは次の3つです。
- エンティティー認証：FIDO 2.0
- アイデンティティー連携：OpenID Connect 1.0 / SAML 2.0
- アクセス認可：OAuth 2.0
エンティティー認証：FIDO 2.0
エンティティーとは人間、法人、モノなど、この世の中の実体のことです。
「人」というエンティティーがあり、その中には「スズキ」という名前の人がいます。その人が本当に「スズキ」であるかを確認することを「ユーザ認証」「利用者認証」といいます。
FIDO
FIDO 2.0 は、FIDO Alliance が策定している「高度エンティティー認証」の方式です。「WebAuthn」「CTAP」という規格です。
ID・パスワードでユーザ認証するサービスは多々あります。FIDO では生体認証デバイスを使ってユーザ認証を行います。たとえば指紋や顔を使って行うユーザ認証です。
アイデンティティー連携：OpenID Connect 1.0
認証を担当したサーバーから、ユーザが利用するサービスサイトに情報を引き渡すことをアイデンティティー連携といいます。
Google認証、Microsoft認証、Apple認証がこのアイデンティティー連携にあたります。
OpenID Connectという国際標準化団体が策定した規格を使っています。こちらは REST、且つ、JSONデータ形式で扱えます。
アイデンティティー連携：SAML 2.0
SAML 2.0 は OpenID Connect よりも前に作られたプロトコルでデータ形式は XML です。
10年以上前からあります。今も多くの企業で使われています。
アクセス許可：OAuth 2.0
アクセス許可をするためのプロトコルです。RFC文章にて仕様が規定されています。
トークンと呼ばれる文字列で許可するかどうかを表します。
ユーザ認証の種類
ユーザ認証の種類は次の3つです。
- オンライン認証：ECサイトやインターネットバンキングなどインターネット上のサービスにログインするケース
- ログインは「メールアドレスとパスワードによるログイン」「他サービスによるログイン」に分けられる
- コールセンターなどでのオフライン認証：電話でお客様番号や生年月日を確認して本人確認するケース
- 対面認証：銀行などで印鑑や通帳などで本人確認するケース
Google や Microsoft はオンライン認証になっており、メールアドレスがログインID になっています。
メールアドレスを ID に使う理由は、自分で覚えておける文字列であり、パスワードを忘れたときにリセットリンクを送れるためです。
電話番号を ID に使うケースもあります。
ログイン画面で ID・パスワードを入力するとサーバーに他の IP などの情報も送られます。さまざまな情報から本人からのアクセスであるかを確認しています。
たとえばスマホを買い替えた直後にログインすると ID・パスワードがあっていても「新しい端末からリクエストされました」とユーザに通知することもあります。
もう一つの方法は「他サービスによるログイン」です。
さきほどの OpenID Connect や SAML を用いたログインで、一般的には「ソーシャルログイン」「SNS認証」という呼び方もされます。
専門的には「認証連携」「Identity Federation」と呼びます。
また、デジタルアイデンティティーを語るときにプライバシーは深く関わります。
なぜならアイデンティティーは「パーソナルデータ」だからです。その人の本名、所属、生年月日などとても価値の高い情報です。
＼ 聞き流せる本！Audilbe無料体験期間中 ／
>> 詳しく知りたい方へ！Audibleで1冊無料でもらう方法を徹底解説
デジタルアイデンティティー要約｜アイデンティティー管理。まとめ。
最初に「エンティティー」「アイデンティティー」「クレデンシャル」について説明します。
エンティティーは「実体」という意味です。これを読んでいるあなたもエンティティー、書くのに使っているパソコンもエンティティーです。
そして、エンティティーである「あたな」を表現するには「スズキタロウ、身長175cm、体重68kg、くせっ毛、メガネをかけた男性」のような感じです。
これを「アイデンティティー」といいます。
あるエンティティー（実体）に関する属性の集合をアイデンティティーです。
アイデンティティー管理では、クレデンシャルという言葉もでてきます。
クレデンシャルは、エンティティーを認証する際に用いるアイデンティティー情報です。
たとえば
- 本人とアイデンティティー管理システムしかしらない秘密の情報（パスワードなど）
- 本人しか知らない・持っていないことを他のシステムが確認できる情報（署名鍵・検証鍵のペア）
- 本人の身体的な特徴（顔、指紋）
- アイデンティティー情報を含むデジタルデータ（トークン）
クレデンシャルとはこのような情報を指します。
エンティティー認証
さきほどのスズキさんのが「メガネをかけた男性」であることは実際に会えばわかるのですが、デジタルの世界ではわかりません。
そこでエンティティー認証が必要になります。種類により指紋を使ったユーザー認証や、パスワードを入力するデバイス認証などです。
認証ができたら「本人」としてシステムが認識します。
またエンティティー認証は「ユーザー認証」「クライアント認証」「サーバー認証」にわかれます。
ユーザ認証は、ユーザ名（またはメールアドレス）とパスワードでログインするケースです。
サーバー認証は、TLS証明書が正しいものであることを確認する方法です。クライアント（ブラウザ）とサービス（サーバー）間でユーザが意識せず行われています。
一方でクライアント認証は、サーバーによって提供されたクライアントシークレットの提示やサーバーに登録した鍵に対応した署名鍵で1回限りのデータに署名してあるかの確認によって実施されることが多いです。
ドコモ口座事件
2020年にエンティティー認証に関する事件が起きました。「ドコモ口座事件」です。
ドコモが銀行と連携することで簡単に口座を作れるサービスです。
双方の認識不足により事件が起きました。
- ドコモは銀行がエンティティー認証をしていると思っていた
- 銀行はドコモが身元確認をしていると思っていた
実際ドコモ、銀行どちらもしっかり確認していなかったことで事件が起きました。
たとえばATMでは以下の要件を満たしているのでセキュリティが高まっています。
- ATMという限られた場所でキャッシュカードと暗証番号での認証を行う
- ATMを使うにはキャッシュカードを保持している必要がある
- PIN（暗証番号）はATMが設置された場所、かつ、キャッシュカードを持っていることが前提で使える
これに対してインターネットでは(1)(2)がありません。そのため(3)のセキュリティが下がります。
これを利用して、他人の口座から不正にお金を引き出した事件です。
銀行の口座名義人＋口座番号＋暗証番号だけでドコモ口座解説できるようになっていました。攻撃者は、どこからか不正に名義と口座番号のリストを入手したとします。
あとは暗証番号を「1234」などに固定して、ドコモ口座開設ができるか試せばいいだけです。
暗証番号を突破されたら他人になりすましてドコモ口座開設が完了し、連携している銀行口座の預金を引き落とすことができてしまったのです。（現在は対策済み）
アイデンティティー管理ライフサイクル
一度アイデンティティーを登録したとしても変わる登録内容は可能性があります。たとえば引っ越せば住所は変わりますし、結婚すれば名字が変わることもあります。
アイデンティティーは、ライフサイクルを意識して管理する必要があります。
5つの状態と9つのプロセスがあります。
状態は次の5つ。
- 不明
- アイデンティティーが登録されておらず分からない状態
- 確率済み
- 必要な情報（アイデンティティー）がアイデンティティーレジスター（IDを管理する場所）に登録された状態
- アクティブ
- エンティティーがアイデンティティーを利用できる状態
例）あなた（エンティティー）がgmailにログインしてアイデンティティー（メール）を利用できる状態
- エンティティーがアイデンティティーを利用できる状態
- 停止
- アイデンティティー情報は存在するが利用を拒否されている状態
- 保管
- アイデンティティーは存在するが通常利用できない状態。たとえば監査のため保持している
状態を9つあります。
- 登録
- アイデンティティーを検証し、アイデンティティーレジスタに登録する
例）マイナンバーカードを発行するときに、住所など本人確認後にシステムに登録すること
- アイデンティティーを検証し、アイデンティティーレジスタに登録する
- 活性化
- エンティティーがリソースにアクセスできるようにするための情報をアイデンティティーレジスターに付与する
例）パスワードの登録
- エンティティーがリソースにアクセスできるようにするための情報をアイデンティティーレジスターに付与する
- メンテナンス・調整
- アイデンティティーレジスターに登録された情報を更新する処理
例）電話番号や住所の更新
- アイデンティティーレジスターに登録された情報を更新する処理
- 停止
- 停止はアイデンティティーレジスターに登録されている情報へのアクセスを停止する
例）クレジットカードの支払いが滞っている
- 停止はアイデンティティーレジスターに登録されている情報へのアクセスを停止する
- 再開
- 停止をしたものを再開する（再開するための条件は必要）
- 保管
- 通常利用できない状態にし、監査などのために保管する
- 削除
- アイデンティティー情報を完全に削除する
一旦保管状態にしてから削除する
- アイデンティティー情報を完全に削除する
- 再確立
- 保管状態にあるデータを通常利用できる状態にする
認証保証レベル
運用方法によってエンティティー認証がどの程度信頼できるか変わります。その信頼度合いを「認証保証レベル」AAL（Authenticator Assurance Level）といいます。
たとえば短い小文字だけのパスワードよりも、長い記号と英数字を組み合わせたパスワードの方が強力です。
しかし、覚えられないので誰でも見れる場所にパスワードを書き写した場合、不適切な運用といえます。
認証保証レベルを考えるときはクレデンシャルの性質と運用を考えることが重要です。
「多要素認証」「多段階認証」という概念があります。似ていますが別物です。
「多要素認証」とは複数の認証要素を組み合わせてエンティティー認証するものです。ID・パスワードの他に、ICカードや生体情報（指紋）などを組み合わせて認証するものです。2種類を組み合わせることを「2要素認証」ともいいます。
「多段階認証」は同じ要素でもいいので複数利用するパターンです。ID・パスワードで認証したあとで、メールアドレスやSMSアドレスに認証コードを送る方法です。
| レベル | 内容 |
|---|---|
| AAL 1 | 安全な認証プロトコルを通じて行われた単一要素以上の認証 |
| AAL 2 | 許可された暗号技術を使った安全な認証プロトコルを通じて行われる。それぞれ認証要素の保持の確認を通じた多要素認証 |
| AAL 3 | 許可された暗号技術を使った中間者攻撃にたいおうした安全な認証プロトコルを通じて行われるハードウェアベースの認証要素の保持の確認を通じた多要素認証 |
＼ 聞き流せる本！Audilbe無料体験期間中 ／
>> 詳しく知りたい方へ！Audibleで1冊無料でもらう方法を徹底解説
デジタルアイデンティティー要約｜アイデンティティー連携フレームワーク「OpneID Connect」。まとめ。
OpenID Connect は 2014年に正式となったアイデンティティー連携のための国際標準です。
OAuth 2.0 の上に作られています（OAuthを拡張してアイデンティティー連携にしたイメージ）。
「いつ認証したのか」「認証した主体の識別子（ユーザID等）」を持っているのでユーザ認証を連携するにも使えます。
OpenID自体が認証といわれることがありますが、あくまで「認証情報を含む属性を連携する規格」です。
主要な規格
- OpenID Connect Core 1.0：OpenID Connectの中核機能の定義。ユーザ属性を連携するために使われる
- OpenID Connect Discovery 1.0：OpenID ConnectクライアントがOpenID Providerの情報を動的に取得する方法を定義している規格。たとえばAサービスがGoogleアカウントでログインできるとしたら、AサービスがGoogleのアイデンティティー管理システムから情報を取得するための規格
- OpenID Connect Dynamic Client Registration 1.0：OpenID ConnectクライアントがOpenID Providerにどのように登録すればよいか定義した規格。たとえばAサービスがGoogleアカウントでログインする機能を作りたい場合、GoogleにAサービスをOpenID Connectクライアントとして登録する必要がある
OpenID Connect Core 1.0
OpenID Connect Core 1.0 で決められていることは「IDトークンの定義」「IDトークンを取得する手続き」「属性値の取得」です。
IDトークンとは、あるユーザに関する情報をまとめて収録し、電子署名を施した上で、1つの文字列にしたものです。つまり、認証済みのアイデンティティーといえます。
IDトークンを見ることで「認証済みかどうか」「どのようなユーザなのか」「どのようなセキュリティか」がわかります。
IDトークンで表せるセキュリティの属性
| 属性名 | 意味 | 必須/任意 | 解説 |
|---|---|---|---|
| iss | 発行者識別子 | 必須 | 発行者を表すURL |
| sub | 主体識別子 | 必須 | ユーザなどの主体の識別子（ユーザIDなど） |
| aud | 宛先 | 必須 | IDトークンの宛先。OAuth2のClient_id |
| exp | 有効期限 | 必須 | IDトークンの有効期限（Unix Time） |
| iat | 作成日時 | 必須 | IDトークンの作成日（Unix Time） |
| auth_time | ユーザー最終認証日時 | （必須） | ユーザーが最後に認証された日時（Unix Time） |
| nonce | 1回限文字列 | （必須） | クライアントのセッションとIDトークンを結びつける、1回だけ使われる文字列。リプレイ攻撃に対抗するために使われる。リプレイは通信を盗聴して、通信をコピーして使うことで他人になりすます攻撃手法。nonceは1回使われたら向こうになるため、通信を盗聴されても、コピーして使ったときには無効になっているため攻撃できない仕組み |
| acr | 認証クラス参照 | 任意 | 認証レベルを表すクラスに対応する文字列。たとえばパスワードによる認証をしたか、など |
| amr | 認証手段参照 | 任意 | 使用された認証手順を表すクラスに対応する文字列 |
| azp | 利用許可者 | 任意 | IDトークンの最終宛先人に対してこのIDトークンを利用することが許可されているOAuthクライアントのclient=id |
| at_hash | アクセストークンハッシュ値 | （必須） | アクセストークンのハッシュ値の左半分。IDトークンとアクセストークンを結びつけ、アクセストークンが置き換えられたりした場合に検知するために使用する。アクセストークンとIDトークンが認可エンドポイントより発行される場合は必須 |
| c_hash | 認可コードハッシュ値 | （必須） | 認可コードのハッシュ値の左半分。IDトークンと認可コードを結びつけ、認可コードが置き換えられたりした場合に検知するために使用する。認可コードとIDトークンが認可エンドポイントより発行される場合は必須 |
ユーザに関する属性
| 属性名 | 意味 | 解説 |
|---|---|---|
| name | 氏名 | ユーザーの氏名 |
| given_name | 名 | ユーザーの名 |
| family_name | 氏 | ユーザーの氏 |
| middle_name | ミドルネーム | ユーザーのミドルネーム |
| nickname | ニックネーム | カジュアルに呼ぶ場合の名前 |
| preferred_username | 希望するユーザ名 | 新規ユーザーの場合は、希望するユーザー名 |
| profile | プロフィールページURL | ユーザーのプロフィールページのURL |
| picture | 写真のURL | ユーザーの写真のURL |
| website | ウェブサイトURL | ユーザーのウェブサイトのURL |
| メールアドレス | メールアドレス（RFC5322に準拠） | |
| email_verified | email属性が確認済みか | email属性が対象ユーザーのものか確認したかを表す |
| gender | 性別 | ユーザーの性別 |
| birthdate | 誕生年月日 | ユーザーの誕生年月日 |
| zoneinfo | タイムゾーン | ユーザーのタイムゾーン |
| locale | 言語 | ユーザーの希望する言語 |
| phone_number | 電話番号 | ユーザーの電話番号 |
| phone_number_verified | phone_number属性が確認済みかどうか | phone_number属性が対象ユーザーのものか確認したかを表す |
| address | 住所 | 住所を表すJSONオブジェクト |
| updated_at | 最終更新時点 | 最後に更新された時点の秒数（Unix Time） |
OpenID Connectのフロー
OpenID Connectにはアイデンティティー連携の流れを定義した3つのフローがあります。
- 認可コードフロー
- インプリシット（暗黙）フロー
- ハイブリッドフロー
認可コードフロー
最もベーシックなフローで、一番多く使われています。
- クライアントが、望むパラメーターを含む認可リクエストを作成する
- クライアントとはあなたの使っているスマホのブラウザなどのこと
- クライアントが、認可リクエストを認可サーバーの認可エンドポイントにWEBブラウザー経由で送信する
- 認可サーバーは利用しようとしているサービスの認可用のシステムのこと
- 認可サーバーがエンドユーザーを認証する
- エンドユーザーとはあたなのこと
- 認可サーバーがエンドユーザーから属性提供の許諾を取得する
- 画面に「許可 / 拒否」の選択肢が表示され、選択する
- 認可サーバーは結果をクライアントにWEBブラウザ経由で戻す。このときにパラメーターに認可コードを付ける
- クライアントは、トークンエンドポイントに認可コードを送信する。可能ならクライアント認証を行う
- 成功すれば、クライアントはIDトークンとアクセストークンを(6)のボディーとして受け取る
- クライアントはIDトークンを検証し、エンドユーザの属性をIDトークンから取得する
- 必要に応じて、アクセストークンを用いて追加属性をUserInfoエンドポイントから取得する
インプリシット（暗黙）フロー
ユーザからの承認・許可を受けたことを明治する認可コードを利用せず、暗黙的にトークンを認可エンドポイントから発呼うするフローです。セキュリティの問題が多く非推奨です。
ただし、認可サーバーがファイヤーウォール内にあったり、携帯端末の中にあったりしてクライアントから直接到達できないが、ブラウザーリダイレクトを使えば到達できる場合には有効なフローです。
- クライアントが望むパラメータを含む認可リクエストを作成する
- クライアントが、認可リクエストを認可サーバーの認可エンドポイントにWEBブラウザー経由で送信する
- 認可サーバーがエンドユーザーを認証する
- 認可サーバーがエンドユーザーから属性提供の許諾を取得する
- 認可サーバーはエンドユーザーをクライアントにWEBブラウザー経由で戻す。パラメーターとしてIDトークンをつける。クライアントはIDトークンを検証し、改ざんされていないか、発行者が正しいか、自分宛てか、nonceがエンドユーザーセッションと結び付けられているか、などを確かめ確認できればエンドユーザをログインさせる。
ハイブリッドフロー
認可エンドポイントから認可コードだけでなく、IDトークンも返すフローです。理由は、認可コードフローは認可応答を改ざん可能であり、それに起因する攻撃が可能であるため。もう一つは、ネットワーク遅延が気になるような状況では、トークンエンドポイントへの往復時間を待たずに、クライアント上での対エンドユーザーの処理を始めたいことがあるためです。
- クライアントが望むパラメーターを含む認可リクエストを作成する
- クライアントが、認可リクエストを認可サーバーの認可エンドポイントにWEBブラウザー経由で送信する
- 認可サーバーがエンドユーザーを認証する
- 認可サーバーがエンドユーザーから属性提供の許諾を取得する
- 認可サーバーは結果をクライアントにWEBブラウザ経由で戻す。パラメーターとして認可コードとIDトークンを付ける。クライアントは受け取ったIDトークンを検証し改ざんされていないことを確認する。
- クライアントはトークンエンドポイントに認可コードを送信する。可能ならクライアント認証を行う。
- 成功すればクライアントはIDトークンとアクセストークンを(6)のボディーとして受け取る
- クライアントはIDトークンを検証し、エンドユーザーの属性をIDトークンから取得する
- 必要に応じて、アクセストークンを用いて追加属性をUserInfoエンドポイントから取得する
FAPI
FAPIはFinancial-grade API Security Profileの略です。OpenID FoundationのFAPI WGで標準が策定されています。2021年3月12日に最終版が出版されました。
FAPIはOpenID Connectをさらにセキュアにしたものです。
FAPIの特徴
- OAuth / OpneID Connectではオプションとされているセキュリティ・プライバシーの機能を必須化
- 持参人型トークンを廃止、すべてを利用者制限トークンに
- セキュリティーはWeb Attacker Model の元で形式検証済み
- 適合性テストスイートと自己認識制度を整備することで実際の互換接続性と安全性を向上
このような特徴があることで多くの地域から注目を浴びており英国、オーストラリア、ブラジルでは標準として採用されました。
＼ 聞き流せる本！Audilbe無料体験期間中 ／
>> 詳しく知りたい方へ！Audibleで1冊無料でもらう方法を徹底解説
デジタルアイデンティティー要約｜アイデンティティ管理によって可能になる「アクセス制御」。まとめ。
アクセス制御は専門用語で「アクセス認可」といいます。
インターネット上で公開されているものでも、誰かが勝手に書き換えできないように何かしらのアクセス制御がかかっています。リソースに対してアクセス許可を与えることが「アクセス認可」です。
たとえば電車に乗るときに改札を通るために切符やSuicaが必要です。これも認可。
インターネットの世界のアクセス制御で最も使われているは OAuth です。
認可はトークンと呼ぶ文字列として取得します。トークンは電車に乗るときの切符のようなものを指します。
アクセス制御の3ステップ
- ユーザー認証
- アイデンティティー管理システムを通してユーザー認証を行う
Googleアカウントでサービスにログインするイメージ
- アイデンティティー管理システムを通してユーザー認証を行う
- アクセス許可
- ポリシーに基づいてアクセスを許すかどうかの決定をし、アクセストークンがユーザーに発行される
写真やドキュメントにアクセスするためにアクセストークンが必要
- ポリシーに基づいてアクセスを許すかどうかの決定をし、アクセストークンがユーザーに発行される
- 認可の執行
- ユーザーが提示たトークンの内容に基づいて許可、拒否が行われる
自分の写真は見れるが、他人の写真は見れなかったり、友達から共有されたドキュメントを参照できたりアクセストークンにより制御される
- ユーザーが提示たトークンの内容に基づいて許可、拒否が行われる
アクセス管理システムの一般系
アクセス管理システムの種類
- 現在のトレンド
- ABAC（Attribute Based Access Control：属性ベースアクセス制御）
- 任意の属性でアクセス制御を行う
- たとえば位置情報（GPS）を使い、座標とユーザーとその他属性を組み合わせてポリシーで評価してアクセス制御を行う
XXXの施設にいる、XXXの状態の人にアクセスを許可する。など
- ABAC（Attribute Based Access Control：属性ベースアクセス制御）
- 以前のトレンド
- IBAC（Identifier Based Access Control：識別子ベースアクセス制御）
- ユーザー名だけでアクセスの可否を判断したり、IPアドレスやMACアドレスで判断するもの
- RBAC（Role Based Access Control：ロールベースアクセス制御）
- IBACは識別子ごとにルールが必要なため数が多くなると管理が大変。そこでロール（役割）という概念を導入し、アクセス制御をロールで行うもの。たとえば「XX部はXXへアクセスできる」のように管理できる
- ユーザーの動的な性質に基づいた制御が苦手なため、ユーザー数によりロールが増えると運用が難しくなる
- IBAC（Identifier Based Access Control：識別子ベースアクセス制御）
またアクセス制御はポリシーや法令に関するコンプライアンスや調査目的のためにモニタリングされる必要があります。
アクセス制御フレームワーク
OAuth 2.0 は現在最も普及しているAPIのアクセス制御フレームワークです。
OAuth認証という言葉も使われますが、OAuth にはユーザーを認証する機能はありません。
正しく理解せずに OAuth を拡張してユーザー認証して大きなセキュリティーホールを生んでしまうことがあります。
そのためユーザー認証するなら OpenID Connect を使いましょう。
OAuth の役割は先程の「改札」そのものです。
OpenID Connect で発行される IDトークンはどんな人（名前・年齢・身長など）を表すものでした。
OAuth はその人がユーザー認証された前提で、あなたには写真とドキュメントを参照する権限を与えます。ということをアクセストークンで表します。
このように使い方が全く違います。
2018年に Facebook は他人のアクセストークンが見れる状態になっていました。そのアクセストークンを使ってユーザー認証もしていたため「アクセストークンを持っている = 本人」となり、その人になりすますことができてしまったのです。5000万人のユーザーアカウントが漏洩したと話題になりました。
＼ 聞き流せる本！Audilbe無料体験期間中 ／
>> 詳しく知りたい方へ！Audibleで1冊無料でもらう方法を徹底解説
デジタルアイデンティティー要約｜企業にとってのアイデンティティー管理。まとめ。
自社システムにアイデンティティー管理を取り入れるときは、OpenID Connect / OAuth Client としての認可サーバーを作ります。
自社に3つのシステムがあり、それぞれで LINEログインを実装しようとすると3つ作る必要があるため大変です。
自社に一つのIDサーバーを用意して、それがまとめて LINEログインを管理することで3つのシステムはその自社の IDサーバーを管理するだけでよくなります。
自社IDサーバーには、ユーザの属性を保存するための「アイデンティティーレジスター」が非中央です。
名前や住所などユーザ情報を保存する場所です。
「アイデンティティーレジスター」には複数のクレデンシャル（たとえばIDトークン）を登録できるようにします。LINEログインを実装したあと、Googleログイン、Facebookログインもしたい！となった場合でも対応できます。
自社から LINE や Google での認証要求するときは一般的にリダイレクトします。
このとき要求に「prompt=none」オプションをつけることで、既存のユーザ認証セッションがある限りユーザー認証ダイアログを飛ばすことができます。
ユーザ認証が成功すると、認可コードが Google から戻されます。
自社IDサーバーはこの認可コードと自らが保存するクライアントクレデンシャルを使って、該当ユーザを説明する IDトークンを Google から取得し、署名検証など IDトークンの確認プロセスに従って内容を確認します。
検証が成功すれば自社IDサーバーは IDトークンから「iss（発行元）」「sub（ユーザーを表す識別子）」を取り出し、アイデンティティーレジスター内で該当ユーザを探し、そのユーザの内部識別子を取得します。
これを使って新たに自社IDトークンを作成し、ユーザのログインを許可とします。
＼ 聞き流せる本！Audilbe無料体験期間中 ／
>> 詳しく知りたい方へ！Audibleで1冊無料でもらう方法を徹底解説
デジタルアイデンティティー要約｜高度化するアイデンティティー管理。まとめ。
サービスサイトと認証サーバー間のセキュリティー高度化 / FAPI
認証サービスとサービスサイト間のやりとりは認証連携で代表的なプロトコルは「OpenID Connect」です。
航空業界の旅客情報や医療データなどに使われるAPIも高度セキュリティーを満たすべきだと言われています。
OpenID Connect、OAuthの文脈では「FAPI (Financial-grade API)」セキュリティープロファイルが該当します。
FAPIの特徴の一つは、持ってきた人が誰であっても有効な「持参人トークン」を廃し、該当トークンに対応した秘密鍵を持っていないと利用できない「使用者制限トークン」を採用したことになります。
つまり、チケットと持っていれば中に入れるのが持参人トークンだとすると、チケット持っていて、且つ、それが保有者だと確認できなれば中に入れないのが使用者制限トークンです。
認証デバイスと認証サーバー間のセキュリティー高度化 / FIDO 2.0
FIDOはパスワードに代わる生体情報（指紋や顔など）での認証です。
2019年は Android 7以降を搭載したスマホがすべて FIDO 2.0 対応しました。2020年9月には iOS14 でもサポートされました。これによりスマホを持っていれば FIDO 2.0 の認証デバイスを持っていることになります。
2段階認証
2段階認証は次のような認証です。
- ID・パスワードでユーザー認証を行う
- SMSでワンタイムパスワードが送信される
- ワンタイムパスワードの認証番号を入力
- ワンタイムパスワードが正しければログインされる
ワンタイムパスワードにていくつかの攻撃を排除できます。
ひとつは「リスト型攻撃」です。どこからか入手したID・パスワードのリストを元にログインできるかを試すものです。
もうひとつは「パスワードスプレー攻撃」です。
たとえばパスワードを「123456」のようなよくあるパスワードに固定し、IDを変えてログインできないか試す攻撃です。
しかし「フィッシング攻撃」にはワンタイムパスワードは効果が薄いのです。偽サイトを用意して、そこにワンタイムパスワードを入力させてしまえば認証を突破できてしまうためです。
このため高度認証の方法としてワンタイムパスワードは不十分であり、FIDO 2.0などの認証方法の導入が望ましいです。
利用者と認証デバイス間認証の高度化 / バイオメトリクス
指紋認証や顔認証のバイオメトリクスが普及するまでは、スマホにパスワードをかける人は少数でした。面倒なためです。
しかし、指紋認証や顔認証によりスマホにロックをかける人が飛躍的に上がりました。
一方で、他人を本人と判定してしまったり、本人なのに認証できないということがあります。ある程度、このリスクを許容する必要があります。そのため生体認証のセキュリティーレベルは3桁の暗証番号と同等とも言われます。
また複製されてしまう危険もあります。グミで指紋を複製して認証を突破しという研究結果もあります。
課題もいくつかあります。
- 全員が FIDO 対応の端末をもっているわけではない
- 振り込め詐欺などで使う口座売買を防げない（一般人が指紋登録付きで口座を作って業者にそれを売ることができてしまう）
- FIDO 認証機を紛失する恐れ
＼ 聞き流せる本！Audilbe無料体験期間中 ／
>> 詳しく知りたい方へ！Audibleで1冊無料でもらう方法を徹底解説
デジタルアイデンティティー要約｜プライバシー保護とアイデンティティー管理。まとめ。
プライバシーの侵害について考えてみましょう。
自分の持っている属性は複数あります。たとえば「性別・身長・体重・髪の色・趣味など」
そして、「自分が知っている自分」と「他人から自分」は違います。他人は自分の属性をすべて知っているわけではありません。
さらに友達に公開している属性と、親に公開している属性は違うと思います。親にだけに公開してた情報を、親が友達に伝えてしまい、友達との関係が変わってしまうことがあります。これがプライバシー侵害です。
プライバシーの原則
- 同意と選択
- ユーザに情報の提供に同意するか、しないか選択させる
- 目的の正当性と規約
- 目的を明確にする必要がある。マーケティングのためのような、ざっくりな目的はNG
- 収集の制限
- 必要最低限のデータのみ取得する。余計なデータは取得しない。
- データの最小化
- 必要最低限のデータしか扱わず、それを触る人も最低限とする
- 利用、保持、開示の制限
- 本人に対して具体的に明示された正当な目的を達成するための必要最低限にとどめる
- データが不要になった場合には確実に破棄、ないしは匿名化する
- 目的を達成したが法令によって保存が求められている場合は、アーカイブとして保管し、通常はアクセスできないようにする
- 正確性と品質
- データが正確ではないと、その人にとって不利なイメージが形成されてしまう恐れがある。
- オープンさ、透明性、通知
- 責任者は誰か、連絡先、処理の目的、処理の方法、データに触れる可能性がある人、など明確にする
- 個人の参加とアクセス
- 本人がデータを確認でき、必要に応じて修正ができる
- 責任ある状態の確保
- 何が起きているか説明できること
- そのことを第三者が検証可能なように記録を取っておくこと
- 第三者検証の結果の説明が間違いであったならば責を負い、罰を受けること
- 情報セキュリティー
- パーソナルデータの完全性、気密性、可用性を確保
- 処理を委任する場合、十分な組織的、物理的などを提供できるものを選任する
- セキュリティーリスクはJIS X 31000などに定められているように体系的に行う
- アクセス最小化を確実にする
- 脆弱性に対処する
- 管理作を定期的に見直す
- プライバシーコンプライアンス
- 法令順守、且つ、プライバシーを守るための内規としてのプライバシーポリシーを順守
参考：すぐそこにあるサイバーセキュリティーの罠
ブログや本を読むのが面倒な方は、聞き流せるAudibleがオススメ！無料で体験できます！
>> 詳細はこちら
＼ 聞き流せる本！Audilbe無料体験期間中 ／
