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