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