Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

#qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」

5,045 views

Published on

#qpstudy 2016.07
第一部 基礎知識編 「ご認証は認可ですか?」

Published in: Technology

#qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか?」

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

×