#qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」
-
Upload
masahiro-nakayama -
Category
Technology
-
view
4.201 -
download
1
Transcript of #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」
![Page 1: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/1.jpg)
第一部 ご認証は認可ですか?基礎知識編 前編
「 Re: ゼロから覚え直す認証・認可」
Aki @ nekoruri#qpstudy 2016.07
![Page 2: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/2.jpg)
アンケート
• 認証・認可どれくらいわかる?1. 超くわしい• 二部で LT しませんか?
2. わかる• おさらいしていってください
3. ちょっとわかる• 考え方の整理のきっかけにどうぞ
4. わからない• 考え方を持ち帰ってください
![Page 3: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/3.jpg)
第一部のあらすじ
• 前編• 「いわゆる認証技術」のおさらい• 認証を取り巻く考え方• ID 管理と ID 連携
• 後編• ID 管理と認証プロトコルの過去と未来
• 第二部「第二部 この素晴らしい統合管理に祝福を」へ• 各社の IDaaS への取り組み
![Page 4: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/4.jpg)
そもそも認証ってなんだっけ?
• ありがちな「認証」で想像してみよう
![Page 5: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/5.jpg)
ひとつのシステム
• たとえば• 会員登録して使うありがちなウェブサービス• VPS に立てた Linux サーバ
• 「ログイン時」に何を渡していますか?
![Page 6: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/6.jpg)
ログインに使う認証情報
• 会員登録して使うありがちなウェブサービス• メールアドレスや会員番号• パスワード• ワンタイムパスワード
• VPS に立てた Linux サーバ• ユーザ名• パスワード• SSH 公開鍵・秘密鍵
![Page 7: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/7.jpg)
認証情報の例
• 本人であることが確かかどうかが分かれば良い• ID とパスワードの組み合わせ• 公開鍵・秘密鍵• ワンタイムパスワード• パスワード再発行
⇒メールアドレスの到達性• SMS やコールバック
⇒電話番号の到達性• 生年月日、住所、干支、秘密の合言葉
⇒(人によっては)公開情報の組み合わせ
![Page 8: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/8.jpg)
アクセス制御
• じゃあログインしてきた人のアクセス制御は?• 所属グループ• 特権( root ユーザ)、 SELinux• ファイルシステムのパーミッション
• システムがひとつなら、そのシステム内で管理できる
![Page 9: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/9.jpg)
複数のシステム
• システムの数だけ認証情報• ID とパスワード• ワンタイムパスワード• 公開鍵・秘密鍵
![Page 10: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/10.jpg)
使い回し問題
• 人類の記憶力にはそこまで余裕が無い• ID =メールアドレス• パスワード=共通
• リスト型攻撃が拡大• どこかで一個漏れるとアウト• ウェブサイトの脆弱性• フィッシング
http://www.ipa.go.jp/about/press/20140917.htmlIPA パスワードリスト攻撃による不正ログイン防止に向けた呼びかけ
![Page 11: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/11.jpg)
システムごとにパスワード
• 人類の記憶力にはそこまで余裕が無い
• パスワード管理ツールの普及• 管理ツールの脆弱性リスク• そもそも PC 上に平文で全てのパスワードが保存されることが良いの
か• このマルウェア全盛期にマスターパスワードは万全では無い
• PC を起動しないと自分のパスワードが分からない⇒ クラウド同期でスマホからも利用 ⇒別のリスクましまし
![Page 12: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/12.jpg)
ワンタイムパスワード
• 原則として、システムごとに異なるワンタイムパスワード• アプリ型ならだいたい複数対応ではあるけれど……• システムの数だけ個別のワンタイムパスワード• つらい
![Page 13: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/13.jpg)
公開鍵・秘密鍵
• 良さそうに見える• 秘密鍵は人類が覚えるには長すぎる• 公開鍵を適切に登録する手間が増える• ウェブサイトで使うには HTTPS クライアント証明書は普及しなさす
ぎ• SSH 公開鍵認証は基本的にシェルログインと SFTP などに限定• 公的個人認証サービス?なにそれおいしいの?• おしい
![Page 14: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/14.jpg)
複数システムにわたるアクセス制御
• 利用者の権限管理• ユーザ情報、グループ情報の同期• ( UNIX ) uid 、 gid が違って NFS でおかしくなる• つらい
![Page 15: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/15.jpg)
ダレカタスケテー• 数が増えたシステムで安全に利用者を認証したい• システムごとにパスワードを覚えるのはつらい• システムごとにワンタイムパスワード用意するのもつらい• HTTPS クライアント証明書は普及していないし、
SSH 公開鍵はシステムを選ぶ
• アクセス制御に必要な情報を交換したい• 管理者は誰?• 利用者はどのグループに入ってるの?
![Page 16: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/16.jpg)
ID 連携
殺伐としたパスワード管理に ID 連携が颯爽と登場
![Page 17: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/17.jpg)
コンシューマ向け ID 連携
• ありがちなソーシャルログインで一気に普及• Twitter• Facebook• Google• mixi
![Page 18: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/18.jpg)
connpass でみる ID 連携
![Page 19: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/19.jpg)
connpass でみる ID 連携
![Page 20: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/20.jpg)
connpass でみる ID 連携
![Page 21: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/21.jpg)
connpass でみる ID 連携
![Page 22: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/22.jpg)
connpass でみる ID 連携
![Page 23: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/23.jpg)
connpass でみる ID 連携
![Page 24: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/24.jpg)
connpass でみる ID 連携
![Page 25: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/25.jpg)
connpass でみる ID 連携
![Page 26: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/26.jpg)
ポイント
• 「 connpass のパスワード」を入力すること無しにログイン• connpass 自身のアカウント( ID )に、
二つのソーシャルログインを「名寄せ」してみた• Twitter (OAuth1.0a)• Facebook (OAuth 2.0)
• 属性情報も取れている• プロフィール情報• 友達のリストとか
注) Facebook は OpenID Connect にも対応していますが、 今はその話はしません。
![Page 27: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/27.jpg)
LDAP での ID 連携
• ユーザ情報、グループ情報、 sudoers を連携• ユーザ情報として SSH 公開鍵も設定
• 全体が一つのシステムのように振る舞う• 一つの認証情報でどのサーバにもログインできる• どのサーバにログインしても同じグループに参加
• NFS で共有されたグループ許可ファイルにアクセス可能• どのサーバでも同じ人が管理者に sudo 可能
![Page 28: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/28.jpg)
この素晴らしい ID 連携に祝福を!
• 管理すべき認証情報の数が大幅に減った!• 一組の認証情報( ID とパスワードや公開鍵など)• 属性情報でアクセス制御も一つに
![Page 29: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/29.jpg)
顧客に必要だったもの
• 認証情報で利用者を「正しく」識別すること⇒認証• 識別された利用者が「やって良いこと」を判断すること⇒認可• これらを適切に管理したい
![Page 30: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/30.jpg)
顧客に必要だったもの
• 認証情報で利用者を「正しく」識別すること⇒認証• 識別された利用者が「やって良いこと」を判断すること⇒認可• これらを適切に管理したい
![Page 31: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/31.jpg)
IAM: アイデンティティとアクセスの管理•むかし(単一システム時代)• Authentication 認証• Authorization 認可• Accouting 記録・監査・課金
• いま(複数システム時代)• Identity アイデンティティ• Access アクセス• Management 管理
![Page 32: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/32.jpg)
IAM: アイデンティティとアクセスの管理•適切に「 Identity 」を管理する重要性が増している• システムの利用者を Identity として適切に区別・管理⇒識別• アクセスしてきた相手の Identity を確実に判断⇒認証• 判断した Identity を元にアクセス可否を判断⇒認可• Identity が行った操作を記録⇒説明責任
• いわゆる「認証関連技術」の目的は Identity の管理• 認証特化した部分• Identity の管理全体に関わる部分
![Page 33: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/33.jpg)
IAM: アイデンティティとアクセスの管理
※本図は CISSPチャリティレビューセミナーの 講義資料より河野様の許可を得て引用
![Page 34: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/34.jpg)
IAM の基礎
• 考え方の整理• Entity (実体)• Identity (コンテキスト依存の属性の集合)
• コンテキスト?• 昔でいえば「システムごと」• 今でいえば「 ID 基盤ごと」
例:「 Twitter の nekoruri 」• 電子的以外の例もあげる
Entity
Identity A
Identity B
Identity C
Context A
Context B
Context C
![Page 35: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/35.jpg)
識別
• Identity を識別するための識別子「 ID 」を発行• Identity の行動を追跡する• 識別子「 ID 」そのものは属性情報の一つだったりもする
• ユーザを共有すると識別ができない• AWS のルートアカウントそのまま使っていませんか?• デフォルトの ubuntu ユーザ共有していませんか?
![Page 36: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/36.jpg)
認証
• 認証プロトコル上でクレデンシャルを送ることで、Entity と Identity の紐付けを検証する• 例)証明書、パスワード、 MFA
• 認証の三要素• 「何を知っているか」(知識情報 ; Something You Know )• 「何を持っているか」(所持情報 ; Something You Have )• 「何であるか」 (生体情報 ; Something You Are )
•古今東西様々な認証プロトコルが存在
![Page 37: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/37.jpg)
認証プロトコル
•暗号化技術の真骨頂• 古くはチャレンジレスポンス(例: APOP )• 最近は PKI への信頼を基にした TLS が主流(中身は平文)
• 認証プロトコルごとに、必要な認証情報も変化• やはり電子証明書は暗号学的に最強
![Page 38: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/38.jpg)
可能な限りパスワードに依存しない
• ID 連携• そもそも認証の回数を減らす。• アプリへも ID 連携を利用し直接パスワードを設定しない
• FIDO UAF• 普段はパスワードを使わず、デバイスに保存された証明書と PIN や生体
で認証を実施• いわゆる Windows 10 がセキュリティ上強いとされる理由の一つ• 最初の一回だけパスワードを入力しないといけない
• リスクベース多要素認証• 環境が変わったら別の手段で追加の確認• オフィスの IP アドレスかつ既知の端末じゃなければ SMS送信、など
![Page 39: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/39.jpg)
それでもやっぱりパスワード
• 「マイクロソフトのパスワードに関するガイダンス」(2016/05/27 https://goo.gl/XtFjRs)
1. 8 文字の最低パスワード長を維持する(必ずしも長いほど良いというわけではない )
2. 文字の組み合わせ ( 複雑さ ) に関する要件を廃止する3. ユーザーアカウントの定期的なパスワード変更を強制しないようにす
る4. わかりやすい一般的なパスワード使うことを禁止する5. 業務アカウントのパスワードを社外他のアカウントに使いまわさな
いようユーザーを教育する6. 多要素認証を必ず利用するようにする7. リスクベース多要素認証の方法を検討する
![Page 40: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/40.jpg)
IoT 時代の認証
• そもそもデバイスごとの「識別」が大前提• IoTデバイス特有の脅威:盗難• そこに置かれている情報は盗まれる• 共有鍵とかダメゼッタイ
http://www.itmedia.co.jp/enterprise/articles/1511/26/news046.htmlITmedia多数メーカーの組み込み機器に同一の秘密鍵、盗聴攻撃の恐れ
• 例) SORACOM• 耐タンパー性のある SIM に証明書が入っている• サービスにアクセスするための認証情報はデバイス側に持たず、
SORACOM側が保持して、適切にプロキシ
![Page 41: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/41.jpg)
認可
• Identity がやって良いこと・悪いことを判断する• ファイルシステムのパーミッション• SELinux のポリシー• クラウドのアクセス制御( AWS の IAM Policy などなど)• connpass イベントの編集画面へのアクセス
• 一般的にはロール(役割)を元に制御する RBAC が多い
管理者ロール
管理機能
管理者全員にアクセス許可
![Page 42: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/42.jpg)
人の認可とアプリの認可の違い
• いわゆるアプリ連携の話• 実はさっきのは「 ID の連携」のための仕組みではない• 実際は「ユーザ情報を取得する権限」を connpass に与え、
connpass が「ユーザ情報を取得する API 」を別に叩いている⇒認可の領域
![Page 43: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/43.jpg)
人の認可とアプリの認可の違い
①ユーザを認証
②アプリに対して API へのアクセスを認可
connpassID
パスワード
connpass 用ID
パスワード
③connpass を認証
④認可されたAPI に対するアクセス
※あくまで概念的な図示で、 通信の内容は異なります。
![Page 44: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/44.jpg)
なぜアプリを認可?
• アプリが直接パスワードを使わなくて済む• パスワード以外の認証方式も利用できる• まだ「 Twitter の ID とパスワード」を入力させるアプリが…… ( つ
Д`)
• アプリごとに、後から権限を剥がすことができる• 例)よくわからない Twitter や Facebook のアプリの解除
![Page 45: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/45.jpg)
説明責任(記録)
• Identity の行動を記録• ふるまいによる不正の検知• 業務内容のエビデンスとしてすべての行動を記録
• コンシューマの ID 連携でも重要• リスト型攻撃の判定• http://www.itmedia.co.jp/enterprise/articles/1607/04/news052.html
splunk>live におけるリクルート社の分析事例
![Page 46: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/46.jpg)
ガバナンスと説明責任
•ガバナンスの話• 現代のマニ車と名高い PDCA
A → P (経営者)↑ ↓C ← D (従業員)• 経営者が計画( Plan )した業務を、従業員が実施( Do )し、その結果の評価内容( Check )を経営者に報告することで、適切に改善( Act )を行う枠組み
•適切な業務記録を残すことで、よりよい判断ができる•エンタープライズ利用で重要な部分
![Page 47: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/47.jpg)
エンタープライズでの ID 管理
•背景:企業で利用する「システム」が増加• 社内の複数システムで Identity が統一されていないと、
その紐付けが面倒・やらない⇒ IT で分析ができない
•裁量をきかせ生産性を上げるには説明責任がセット ⇒ 記録を容易に残すために ID 連携で紐付け
• パスワード管理という以上に、企業における ID 管理・ ID 連携の重要性が増している
![Page 48: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/48.jpg)
前半のまとめ
• 「認証技術」の本質はアイデンティティとアクセスの管理• 利用者の識別と認証• 利用者の行動の認可と記録
• 脆弱な「パスワード」との戦いは技術的には、ほぼ終止符• ID 連携:そもそも認証の回数を削減• FIDO UAF:普段はパスワードを使わない• リスクベース多要素認証:環境が変わったら別の手段で追加の確認
![Page 49: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/49.jpg)
休憩はさんでここから後半
![Page 50: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/50.jpg)
第一部 ご認証は認可ですか?基礎知識編 後編
「認証帝国興亡史」
Aki @ nekoruri#qpstudy 2016.07
![Page 51: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/51.jpg)
で、誰?
• あき•ねこるり etc.
![Page 52: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/52.jpg)
前半のまとめ
• 「認証技術」の本質はアイデンティティとアクセスの管理• 利用者の識別と認証• 利用者の行動の認可と記録
![Page 53: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/53.jpg)
前半のまとめ
• 「認証技術」の本質はアイデンティティとアクセスの管理• 利用者の識別と認証• 利用者の行動の認可と記録
• 脆弱な「パスワード」との戦いは技術的には、ほぼ終止符• ID 連携:そもそも認証の回数を削減• FIDO UAF:普段はパスワードを使わない• リスクベース多要素認証:環境が変わったら別の手段で追加の確認
![Page 54: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/54.jpg)
後半
• ID 管理と認証プロトコルの歴史をおいかけます• 初期の頃は、 ID 管理と認証プロトコルが混在しているので、
ここでも並列して取り上げていきます。
![Page 55: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/55.jpg)
古代
•職人が芸術的に設定• ファイルで配布• 自分も詳しくないので省略
![Page 56: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/56.jpg)
中世
• 考え方やモデルとしての元祖達• NIS / NIS+• Kerberos• Radius• X.500• コールバック
![Page 57: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/57.jpg)
NIS / NIS+• Sun が 1980 年代に開発した元祖 ID 管理システム• Network Information Service• 2000 年前半くらいまではそこそこ現役
•ざっくり言えば /etc/passwd /etc/hosts の共有を実現• 認証は各サーバがハッシュ化パスワードを読んで実施
• そのまま LDAP にシフト• 基本的に Sun製品• 性能問題• セキュリティ
![Page 58: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/58.jpg)
Kerberos• MIT が 1980 年代に開発• クライアントサーバモデルでのシングルサインオン• クライアントが複数のサーバを利用できる
• 共通鍵暗号をベースに設計• KDC ( Key Distribution Center )が良い感じに認証• KDC は全ての利用者・サーバとの共通鍵を持つ• 「チケット」というセッション鍵を発行
•今でも Active Directory の認証処理は Kerberos
![Page 59: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/59.jpg)
RADIUS• 「 Remote Authentication Dial-In User Service 」という名
前の通り元はダイヤルアップ回線のユーザ管理• 「 AAA 」モデルという呼称が広まるきっかけ• Accounting (記録)という考え方が既に入っている• LAN接続の認証に利用される「 IEEE 802.1X 」で現役
![Page 60: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/60.jpg)
X.500• ITU-T が定めた分散ディレクトリの規格• ID 管理の基盤となる規格• Novell Directory Service や NT ドメインを経由して、
Active Directory のモデルの基礎になっている。• LDAP の Lightweight は、この X.500 に対する「 Lightweight 」
![Page 61: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/61.jpg)
コールバック
•多要素認証の元祖• ダイヤルアップで接続しようとすると、
サーバ側から折り返し電話がかかってくる。
![Page 62: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/62.jpg)
近代
• だいたい現役世代• LDAP• Active Directory• ( OpenID )• OAuth• SSH• ワンタイムパスワード
![Page 63: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/63.jpg)
LDAP• Lightweight Directory Access Protocol• 「 X.500 の 90% の機能を 10% のコストで実現する」として 1993
年に公開• 組織ごとに LDAP サーバを立てて、他のサーバやクライアントが
LDAP クライアントとして問い合わせしに行く。
•ディレクトリの階層構造とユーザー属性• dn: dc=example,dc=com
• dn: ou=People,dc=example,dc=com• dn: uid=aki,ou=People,dc=example,dc=com
mail: [email protected]: aki
• SSH の公開鍵を入れたりもできる
![Page 64: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/64.jpg)
LDAP• バインド• ディレクトリにはファイルシステムのようなパーミッションが設定• LDAP サーバに接続するときに認証情報を送ることで、
そのユーザで取得可能な情報をコントロールできる• 「 ID とパスワードが一致して認証成功したら、成功結果を返す」• 「自分自身の情報は変更が可能」• 「他の人の情報は名前の検索のみ可能」• などなど
•入力されたパスワードを LDAP サーバにそのまま送信• 最近はサーバまで TLS で暗号化することが多い
![Page 65: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/65.jpg)
Active Directory• Windows2000 で登場• DNS と LDAP と Kerberos をベースに Microsoft が拡張したもの
• ユーザやコンピュータの情報を LDAP に格納• ユーザやコンピュータにグループポリシーを適用できる
• 認証は Kerberos で実施• 暗号化は最近は AES (さすがにオリジナルの DES ではない)
•詳しくは第二部?
![Page 66: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/66.jpg)
OpenID• ウェブにおけるオープンな ID 連携の元祖
• それまで、商用製品のクローズドなシングルサインオン製品などのみ• 2 本では 2007 年あたりに最初の流行
• ID を第三者のサイトに知らせる仕組み• OpenID Provider(OP)ID を発行して認証サービスを提供• Relying Party(RP) ID を受け取る第三者サイト
• OAuth を利用した「認証っぽい機能」も提供した Twitter と Facebook の人気により (惜しくも )下火へ• まさに「 ID 連携」いろいろなサービス間連携の裏側で動いていたりしました。
![Page 67: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/67.jpg)
OAuth• Twitter や Facebook のサードパーティアプリ連携として提供• ある権限を第三者に与える仕組み• 「 Twitter でツイートする権限を Janetter に与える」• 「 Facebook のプロフィール情報を見る権限を connpass に与え
る」
• 「自分のプロフィール取得」という権限が ID 連携と近いため、長い間「 OAuth 認証」などとして利用されることに……
![Page 68: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/68.jpg)
アプリの認可(再掲)
①ユーザを認証
②アプリに対して API へのアクセスを認可
connpassID
パスワード
connpass 用ID
パスワード
③connpass を認証
④認可されたAPI に対するアクセス
※あくまで概念的な図示で、 通信の内容は異なります。
![Page 69: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/69.jpg)
OAuth の種類
• OAuth 1.0a• みんなだいすき Twitter で採用• 平文での通信を考慮したため必要以上に複雑• セキュリティの考慮が甘かったため、詰めが甘い
• OAuth 2.0• Facebook 、 Google 、 GitHub 、 LinkedIn などが採用• もろもろの問題を解決
![Page 70: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/70.jpg)
SSH• (ちょっと毛色は違いますが)主にシェルログインに使われる暗号化プロトコル
•様々な認証プロトコルを利用可能• (暗号化通信路の上で)そのままパスワード送信• 公開鍵認証
• おそらく世界で一番使われているクライアント認証?
![Page 71: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/71.jpg)
ワンタイムパスワード
•主に二要素認証で「もう一つのパスワード」に使われる• 「何を持っているか」で認証を行う
•様々なパターン• ハードウェアトークン• ソフトウェアトークン• SMS• 電話
https://commons.wikimedia.org/wiki/File:SecureID_token_new.JPG
![Page 72: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/72.jpg)
現代
• SAML• OAuth Connect• SCIM• FIDO
![Page 73: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/73.jpg)
SAML•主に企業用途で使われる ID 連携プロトコル• 2000 年代前半に登場• シングルサインオンの分野で伸びてきた• エンタープライズでの ID 連携としての実績
• IdP から SP に ID やその属性情報を送る• IdP Identity Provider (ID 情報を送る側 )• SP Service Provider (ID 情報をもらってサービスを提供する側 )
•詳しくは第二部で!
![Page 74: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/74.jpg)
OpenID Connect• OpenID の最新版• OAuth 2.0 をベースに ID 連携のための機能を整備• 見え方としては、前半の connpass と Facebook 連携とほぼ一緒• ユーザ属性を定義したり、様々なパターンで使いやすくなった
• ID 連携で今後最も重要なプロトコル!
![Page 75: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/75.jpg)
SCIM• System for Cross-domain Identity Management • ID 情報のプロビジョニング• 従来でいえば LDAP や情シスの中の人が手作業で頑張っていた部分
• CSP に登録・削除された ID 情報を ECS に反映• CSP Cloud Service Provider ( IdP )• ECS Enterprise Cloud Subscriber ( RP )
![Page 76: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/76.jpg)
プロビジョニング?
• リソースの事前準備• ID 管理で具体的にいえば• ログインする前に ID 連携先にユーザを作成• 削除された ID を連携先でも削除• 連絡先などでリストに表示
こういったことをやるための ID 情報のデータ同期•入退社作業職人が不要に!
![Page 77: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/77.jpg)
FIDO• 認証プロトコルの大本命• Windows 10 と NTT ドコモ参加表明で昨年話題に
• 大きく二つの枠組み• FIDO U2F いわゆる「多要素認証」• FIDO UAF
![Page 78: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/78.jpg)
FIDO UAF• パスワードを使わないログイン• 生体認証( Windows Hello )• PIN ログイン• TPM等を利用
証明書秘密鍵
PIN でロック
証明書秘密鍵
ロック解除
PIN
証明書秘密鍵
ログイン先
ログイン試行
証明書秘密鍵
再度ロック
![Page 79: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/79.jpg)
現状のまとめ
• コンシューマ向け• OpenID Connect + OAuth
•エンタープライズ向け• SAML or OpenID Connect• SCIM
• UNIX/Linux サーバログイン• LDAP
• クライアント PC• FIDO
![Page 80: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/80.jpg)
ID の管理
• ID を適切に管理するには属性情報が必要• 組織図に応じた権限管理• 従業員種別とか• LDAP に入れた SSH 公開鍵の話とか
• ID 連携における属性情報の管理方法• LDAP 、 Active Directory• OpenID Connect での属性受け渡し
•色々詰めていくと実はここが面倒そう?
![Page 81: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/81.jpg)
IDaaS の登場
• 2016 年にもなって ID 管理自前でやるの?つらくない?• ID 連携で引っ張れるようになったんだから、
ID 管理の部分は任せた方が良くない?
•面倒なことは餅は餅屋に• もう誰もクレカ決済自前でやらないよね?• 従業員の情報とかも個人情報だしね……• 国ぐるみ IDaaS……
•続きは第二部で!
![Page 82: #qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」](https://reader033.fdocument.pub/reader033/viewer/2022061306/587fc1a61a28ab3b158b539d/html5/thumbnails/82.jpg)
第一部のまとめ
• ID 管理は大事だよ• 識別、認証、認可、記録• すべて「適切な ID 」があってこそ
• 認証技術は実はもう決定打が揃いつつある• ID 連携、 FIDO UAF 、リスクベース多要素認証
•餅は餅屋! ID 管理は IDaaS!続きは第二部「この素晴らしい統合管理に祝福を」で!
「おいおい、場外乱闘始まったぞ!」 「酒でも飲みながら観戦するか!」