#qpstudy 2016.07 第一部 基礎知識編 「ご認証は認可ですか？」
445 Views
July 16, 16
スライド概要
#qpstudy 2016.07
第一部 基礎知識編 「ご認証は認可ですか？」
秋葉原生まれ大手町育ちの歌って踊れる江戸っ子インフラエンジニア。 0と1が紡ぐ「ゆるやかなつながり」に魅せられ早20年、 SNSとCGMの力で世界を幸福にするのがライフワーク。 市民、幸福は義務です。 あなたは幸福ですか？
関連スライド
各ページのテキスト
第一部 ご認証は認可ですか？ 基礎知識編 前編 「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.html IPA パスワードリスト攻撃による不正ログイン防止に向けた呼びかけ
システムごとにパスワード • 人類の記憶力にはそこまで余裕が無い • パスワード管理ツールの普及 • 管理ツールの脆弱性リスク • そもそも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（コンテキスト依存の属性の集合） Identity A Context A Identity B Context B Identity C Context C • コンテキスト？ • 昔でいえば「システムごと」 • 今でいえば「ID基盤ごと」 例：「Twitterのnekoruri」 • 電子的以外の例もあげる Entity
識別 • 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.html ITmedia多数メーカーの組み込み機器に同一の秘密鍵、盗聴攻撃の恐れ • 例）SORACOM • 耐タンパー性のあるSIMに証明書が入っている • サービスにアクセスするための認証情報はデバイス側に持たず、 SORACOM側が保持して、適切にプロキシ
認可 • Identityがやって良いこと・悪いことを判断する • • • • ファイルシステムのパーミッション SELinuxのポリシー クラウドのアクセス制御（AWSのIAM Policyなどなど） connpassイベントの編集画面へのアクセス • 一般的にはロール（役割）を元に制御するRBACが多い 管理者ロール 管理者全員に アクセス許可 管理機能
人の認可とアプリの認可の違い • いわゆるアプリ連携の話 • 実はさっきのは「IDの連携」のための仕組みではない • 実際は「ユーザ情報を取得する権限」をconnpassに与え、 connpassが「ユーザ情報を取得するAPI」を別に叩いている ⇒認可の領域
人の認可とアプリの認可の違い Twitter ③connpassを認証 ①ユーザを認証 ④認可された APIに対するアクセス ID パスワード ②アプリに対して APIへのアクセスを認可 connpass connpass用 ID パスワード ※あくまで概念的な図示で、 通信の内容は異なります。
なぜアプリを認可？ • アプリが直接パスワードを使わなくて済む • パスワード以外の認証方式も利用できる • まだ「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: aki@example.com uid: 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認証」などとして利用されることに……
アプリの認可（再掲） Twitter ③connpassを認証 ①ユーザを認証 ④認可された APIに対するアクセス ID パスワード ②アプリに対して APIへのアクセスを認可 connpass connpass用 ID パスワード ※あくまで概念的な図示で、 通信の内容は異なります。
OAuthの種類 • OAuth 1.0a • みんなだいすきTwitterで採用 • 平文での通信を考慮したため必要以上に複雑 • セキュリティの考慮が甘かったため、詰めが甘い • OAuth 2.0 • Facebook、Google、GitHub、LinkedInなどが採用 • もろもろの問題を解決
SSH • （ちょっと毛色は違いますが） 主にシェルログインに使われる暗号化プロトコル • 様々な認証プロトコルを利用可能 • （暗号化通信路の上で）そのままパスワード送信 • 公開鍵認証 • おそらく世界で一番使われているクライアント認証？
ワンタイムパスワード • 主に二要素認証で「もう一つのパスワード」に使われる • 「何を持っているか」で認証を行う • 様々なパターン • • • • ハードウェアトークン ソフトウェアトークン SMS 電話 https://commons.wikimedia.org /w iki/File:SecureID_token_ne w.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！ 続きは第二部「この素晴らしい統合管理に祝福を」で！ 「おいおい、場外乱闘始まったぞ！」 「酒でも飲みながら観戦するか！」