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.

マルチクラウド時代に求められる ID & シングル・サインオン(SSO)基盤とは?

1,046 views

Published on

[2018/10/24に開催した「Lead Initiative 2018 Technical TRACK」の講演資料です]
今日、企業におけるクラウドサービスの採用率は半数を大きく超え、マルチクラウドも当たり前の世界になりつつあります。その結果、それぞれのクラウドサービスのID管理に悩まれている方も少なくないのではないでしょうか。本講演では、マルチクラウド運用の現状と、そこで生じるID管理の課題、注意点などを踏まえ、マルチクラウドに求められる ID&SSO基盤について解説します。
講演者:渡辺 尚徳(ネットワーク本部 プロダクト推進部 企画業務課)

Published in: Internet
  • Be the first to comment

  • Be the first to like this

マルチクラウド時代に求められる ID & シングル・サインオン(SSO)基盤とは?

  1. 1. マルチクラウド時代に求められる ID&シングル・サインオン(SSO)基盤とは? ネットワーク本部 渡辺 尚徳
  2. 2. クラウドサービス利用にあたっての 現状と潜在リスクと課題
  3. 3. 多くの企業に利用されているクラウド 4 9.7% 16.0% 21.8% 28.2% 35.2% 50.9% 59.3% 0.0% 10.0% 20.0% 30.0% 40.0% 50.0% 60.0% 70.0% H21年度H22年度H23年度H24年度H25年度H26年度H27年度H28年度 クラウド・コンピューティング利用率 「経済産業省/平成29年度情報処理実態調査」 を元にIIJで作成 新規システムの構築方法 「株式会社MM総研2014/11/04 ニュースリリース」 を元にIIJで作成 16% 13% 11% 38% 22% 原則的にクラウド事業者のプライベートクラウド 原則的に自社資産のプライベートクラウド 原則的にパブリッククラウド 都度、クラウドサービスとオンプレミスのどちらか最適か検討 原則的にオンプレミス 約8割の企業が新規システムの 構築時にクラウドを検討 ■今や過半数の企業がクラウドを利用 ■8割の企業が新規システムの構築時にクラウドを検討。 クラウドファーストの浸透が顕著
  4. 4. マルチクラウド利用の時代に クラウドとオンプレミスのシームレスな連携を要求 ID管理者はプロバイダー兼ブローカ(IDブローカ)としての 振る舞いが必要 クラウドの適用範囲が広がり、マルチクラウド利用が当たり前の時代になりつつあります。 結果、より多くのオンプレミスとクラウドの連携やクラウドとクラウド間の連携が今後求められてきます。 今後 現在 過去 オンプレミスのみの利用 • クラウドとの連携なし 限定的なクラウドの利用 • 情報系としての利用 • 少数のクラウドとの連携 積極的なクラウドの利用 • 基盤系としての利用 • 多数のクラウドとの連携 ユーザ ID管理者 オンプレミス プライベート クラウド パブリック クラウド ハイブリッド クラウド 5
  5. 5. 課題&潜在リスク① ID&SSO基盤の対応 ID/SSO基盤によりオンプレミスは最適化されたが、 クラウドサービスの利用が進み、マルチクラウドへの適用が課題に ユーザ ID管理者 HR CSVID基盤 構築/運用コストが高い お客様環境 マルチクラウドの時代へ 各クラウドの ID更新を 個別で実施 各クラウドごとに 異なるID/PWでの ログインが必要 Active Directory LDAP RDB ポータルサーバ グループウェア ERP SSO基盤 SSOレポジトリ オンプレミスシステムの 各Webサイトに1つのIDで シングルサインオン オンプレミスシステムの ID管理フローの一元化 クラウドへの対応が難しい 6
  6. 6. 課題&潜在リスク② ID/PW漏洩 実在の組織や社員を 語るメールを送信 本文に記載されたURLを踏むと 巧妙な偽サイトに誘導 攻撃者 ユーザ 攻撃の起点になりやすいメールサービスに対して、 ビジネスメール詐欺やフィッシング詐欺が仕掛けられ、 ID/PWが漏洩する事例が多く報告されています。 7 メールのID/PWなどの入力を要求させ、 ユーザのID/PWを奪取 Office 365 の画面などに似せた 巧妙なフィッシングサイト
  7. 7. 課題&潜在リスク③ ID/PW漏洩からの二次被害 ■記憶可能なID・パスワード数は平均3.1組 ID・パスワードの記憶可能数(N=1,000) 「野村総合研究所/インターネットユーザーのIDに関する意識について」 を元にIIJで作成 ■パスワードの使い回しから不正ログインが起こるまで ユーザ ① 同 一 パ ス ワ ー ド を 使 い 回 し ② 漏 え い ③ 不 正 ロ グ イ ン クラウドA クラウドB クラウドC 攻撃者 8.8% 54.5% 21.7% 0% 20% 40% 60% 80% 100% 1組でも自信がない 1組 2~3組 4~5組 6~9組 10組以上 メールで漏洩したID/PWを用いたアカウントリスト攻撃により、 他クラウドサービスも不正ログインの被害に 8
  8. 8. 課題&潜在リスク④ 法規制(個人情報保護) 日本国内での運用だけ考えても、ID/パスワードだけでの情報保護の限界を踏まえ、PCI DSSや経済産 業省のクラウドセキュリティガイドラインでも多要素認証の導入の必要性を謳っています。 PCI DSS v3.2 要件 8: コンピュータにアクセスできる各ユーザに一意の ID を割り当てる 8.3.1 管理アクセス権限を持つ担当者のすべてのコンソール以外のカード会員データ環境への管理アクセスに多要素認証を組み込む。 注: この要件は、2018年1月31日まではベストプラクティスとみなされ、それ以降は要件になります。 8.3.2 ネットワーク外部からのネットワークへのリモートアクセスすべてに (ユーザと管理者、サポートやメンテナンス用の第三者の アクセスを含む)多要素認証を組み込む。 経済産業省 「クラウドセキュリティガイドライン活用ブック」より クラウド上のID管理においてはネットワークからの攻撃を受けるため、パスワードの複雑さだけではなく、二要素認証や二段階認証などの単体 のパスワードの強度だけに依存しない対策を行うことが重要です。また、クラウドサービスを選択する際にも、コントロールパネルやユーザ管 理においてこれらの認証機能が選択できるところを選択するのが良い。 9
  9. 9. マルチクラウドに求められる ID&SSO 基盤とは
  10. 10. マルチクラウドのID&SSO管理での必要要素 11 認証管理 (Federation) セキュリティ強化/ 多要素認証 ID管理
  11. 11. マルチクラウドへの認証管理 12 認証管理 (Federation) セキュリティ強化/ 多要素認証 ID管理
  12. 12. オンプレミスにおけるSSO方式(おさらい) エージェント リバースプロキシ 代理認証+リバースプロキシ システム構成 クラウドとの SSO連携可否 × • クラウドへのエージェント導入が 不可であるため、クラウドとの連 携方式としては不可 × • クラウドにも認証機構が存在してい るため、代理認証との併用が必要 △ • 代理認証を経由してクラウドでの認証が可能 だが、インターネット上へIDとパスワードが 送信されてしまう 既存システムの 変更要否 × • 既存システムにエージェントを組 み込む必要がある • ネットワーク構成を変更する必要 が無い △ • 既存システムの改修が不要 • 必要に応じて、全てのアクセスがリ バースプロキシを経由するように ネットワーク構成の変更が必要 △ • 既存システムの改修が不要で、既存システム にフォーム認証がある場合にも連携可能 • 全てのアクセスが代理認証プロキシを経由す るようネットワーク構成の変更が必要 大規模システム への対応 ○ • アクセスが各システムに分散され るため、大規模やトラフィック密 度の高いシステムに最適 △ • アクセスがリバースプロキシに集中 するため、大規模やトラフィック密 度の高いシステムに不向き △ • アクセスが代理認証プロキシに集中するため、 大規模あるいはトラフィック密度の高いシス テムに不向き オンプレミスのSSO方式をそのままクラウドには適用できないため、新しい技術の導入が必要 認証サーバ WEBシステム リバースプロキシ WEBシステム 認証サーバ 代理認証プロキシ WEBシステム 認証サーバ エージェント クラウドとSSOの連携を行うために新しい技術の導入が必要 13
  13. 13. Federation技術の発展 フェデレーションは2000年以降の技術であり、複数の技術仕様が発展を重ねてきている 現在2000年 SAML 1.0 SAML 2.0 OAuth 1.0 OAuth 2.0 OpenID Connect OpenID 2.0 OpenID 1.0 WS- Federation 1.0 WS- Federation 1.1 WS- Federation 1.2 14
  14. 14. Federation技術の比較 各プロトコル仕様を比べるとそれぞれに特徴があるため、 全体のシステムの構成やクラウドの仕様等に合わせて活用するプロトコルを選定する事が必要 SAML 2.0 WS-Federation 1.2 OpenID Connect OpenID 2.0 OAuth 2.0 認証 認可 機能 ブラウザ以外 のアクセス (アプリ) △ • 実際に広く利用されているの は Web ブラウザのみ △ • SOAP・その他のスマート クライアントを規定 ○ × • Web ブラウザのリダイレ クト機能に依存 ○ 認証連携 ○ ○ ○ ○ × • 仕様外 属性情報の流通 ○ ○ ○ ○ × • 仕様外 システム間認可 (Web API アクセス許可) △ • 仕様外、ただし OAuth2.0と の組合せが可能 × • 仕様外 ○ △ • OAuth 1.0 とのハイブ リットで対応可能 ○ セキュ リティ 認証、属性情報へ の署名、暗号化 ○ ○ • WS-Trust にてサポート ○ △ • 共有鍵による署名のみ可、 暗号化は仕様外 × • 仕様外 認証時の 情報送付 ○ • 認証時にIDやパスワードの情 報を送信しない ○ • 認証時にIDやパスワードの 情報を送信しない ○ • 認証時にIDやパスワードの 情報を送信しない × • 認証時に平文のID情報を送 信する ○ • 認可時にIDやパスワードの 情報を送信しない 総合評価 ○ • BtoB 向け • 予め連携間で設定が必要 • 様々なユースケースに適用可 能な仕様であり、エンタープ ライズでの普及が進み対応可 能なクラウドも多い △ • BtoB向け • 予め連携間で設定が必要 • 主にMicrosoft社製のクラウ ドで利用可能であり、導入 可能範囲が限定的 △ • 認証、認可とも十分な機能 をもっているが、商用サー ビスへの普及はまだこれか らであり、現時点の普及度 が限定的 △ • BtoC向け • システム間での信頼関係を 結ぶ必要がなくコンシュー マーサービスでは普及が進 んでいるが、エンタープラ イズでの普及度が限定的 • OpenID Connectに移行中 ○ • 認証の規格ではなく、 認可の規格 • Web APIアクセス許可の事 実上フレームワークとして広 く普及しているが、 ID連携 は対象外であるためSAML併 用が多い 15
  15. 15. SAMLとは? ブラウザのオートリダイレクト機能を利用し、クライアント&各サービスともエージェントレスで、 認証時ID/PW情報を流さないXMLをベースにした標準規格 SSO基盤 (SAML IdP(アイデンティティプロバイダ)) クラウドサービス (SAML SP(サービスプロバイダ)) ① 利用者がクラウドサービスにアクセス ② (事前設定に基づき) 指定されたSSO基盤へ オートリダイレクト ③ SSO基盤でユーザ認証 クライアントのブラウザ ⑤ ログインを許可 ④ (事前設定に基づいた) オートリダイレクトにて SAMLアサーションリクエストを添付 お互いのサービスに事前に下記を設定 • お互いのサービスのURL • お互いのユーザをユニークに紐付ける属性 • 共有鍵 エージェントなどは必要なし SAML 16
  16. 16. SAMLアサーションリクエスト時に流れる電文 SAMLアサーションメッセージ <samlp:Response xmlns:samlp=“urn:oasis:names:tc:SAML:2.0:protocol” ID=“s27b1cdd16f6f7f8e6c952289f7f0dde656ef70a24” InResponseTo=“_4301ad51-d9c0-4ca0-938f-f82ee2405112” Version=“2.0” IssueInstant=“2016-07-20T00:19:05Z” Destination=“https://login.microsoftonline.com/login.srf”> //SP 先 <saml:Issuer xmlns:saml=“urn:oasis:names:tc:SAML:2.0:assertion”>発行元 IDP ID</saml:Issuer> <samlp:Status xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"> <samlp:StatusCode xmlns:samlp=“urn:oasis:names:tc:SAML:2.0:protocol” Value=“urn:oasis:names:tc:SAML:2.0:status:Success”> //応答ステータスコード </samlp:StatusCode> </samlp:Status> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="s2ca8197b6ccc0d64efbd7249504998e0a00a93f26" IssueInstant="2016-07-20T00:19:05Z" Version="2.0"> <saml:Issuer>XXXXXXXXXXXX</saml:Issuer> <ds:Signature xmlns:ds=“http://www.w3.org/2000/09/xmldsig#”>XMLデジタル署名</ds:Signature> <saml:Subject> <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier=発行元IDP ID SPNameQualifier=“urn:federation:MicrosoftOnline” //SP 名 SPProvidedID="b77e8ac2-1762-46a3-a66a-7550912234e9">b77e8ac2-1762-46a3-a66a-7550912234e9</saml:NameID> //SP ID <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:SubjectConfirmationData InResponseTo="_4301ad51-d9c0-4ca0-938f-f82ee2405112" NotOnOrAfter="2016-07-20T00:29:05Z" Recipient=“https://login.microsoftonline.com/login.srf”/> //SP 先 </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore="2016-07-20T00:09:05Z" NotOnOrAfter="2016-07-20T00:29:05Z"> <saml:AudienceRestriction> <saml:Audience>urn:federation:MicrosoftOnline</saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2016-07-20T00:19:05Z" SessionIndex="s240a4b682e9b43f056eec23eb49f16937c9a72401"> <saml:AuthnContext> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> <saml:AttributeStatement> <saml:Attribute Name="IDPEmail"> <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xsi:type=“xs:string”>予め指定した連携属性の値</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion> </samlp:Response> 連携の際に伝達される情報は、 限られた情報だけ! デジタル署名で保護! 下記の情報がブラウザを介して伝達されます。この中には連携先のID/PWは含まれません。 ※ Office 365とのSAMLを用いた認証連携例 17
  17. 17. マルチクラウドへのセキュリティ強化/多要素認証 18 認証管理 (Federation) セキュリティ強化/ 多要素認証 ID管理
  18. 18. ID/PWだけでは認証させない仕組みが必要 19 詐欺被害を抑えるには「認証セキュリティ」が重要で、 ID/PW認証+アルファの対策が必要
  19. 19. ID/PWの漏洩に対するアプローチ案 20
  20. 20. ID/PWの漏洩に対する対策方法 21 ※ Office 365での対策例
  21. 21. マルチクラウドへのID管理 22 認証管理 (Federation) セキュリティ強化/ 多要素認証 ID管理
  22. 22. ID管理は各クラウド独自の現状 • 認証(Federation)とは異なり、各クラウド間でID管理用の統一されたAPIは存在していません。 • SCIM(System for Cross-Domains Identity Management)という取り込みもあるが まだ市民権を得られている状態にはなっていません。 • 結果、あらゆるクラウドにID管理が実現できるID基盤は存在しません。 • 各クラウド側でID管理用のインターフェースは様々です。 • 独自 REST API として公開 • SCIM として公開(独自拡張スキーマを定義して利用させる場合もあり) • ADとの自動連携モジュールを提供 • CSV インポート機能としてのみ提供 • etc... • 各クラウドでアカウントの作成/変更/削除の機能も様々 • 例: Salesforceではアカウント削除用のAPIはなく、アカウント無効化処理に置き換えて対策が必要など • ID管理インターフェースがAPIとして公開されているのであれば、 API Gateway製品を活用し、汎用的な SCIM や REST API のリクエストをAPI Gatewayに投げ、 そこから各クラウドのID管理用APIに変換して流し込むということは可能ですが、 それなりの投資が必要となります。 23
  23. 23. クラウドに対するID管理で考慮した方がいい事 24 ID管理者 HR CSV ID基盤 お客様環境 Active Directory API変換サービス CSV転送サービス 各クラウドサービス側提供 AD同期モジュール ADを起点とした同期配信基盤を ユーザデータの加工はID基盤で一元処理 ADから各クラウド間のID同期は 連携アプローチに問わず 原則ADのユーザデータを無加工で 右から左へ渡すようなアプローチで API Gateway製品で置き換えは可能だが コストもそれなりに掛かるので SIした方がよいかどうかとコスト見合いで 現行の対策としてはADを起点とした連携が現実的
  24. 24. まとめ: マルチクラウドに求められるSSO管理 25 認証管理 (Federation) セキュリティ強化/ 多要素認証 ID管理 Federation Federation Federation
  25. 25. まとめ: マルチクラウドに求められるID管理 26 認証管理 (Federation) セキュリティ強化/ 多要素認証 ID管理 ID管理者 HR CSV ID基盤 お客様環境 Active Directory API変換サービス CSV転送サービス 各クラウドサービス側提供 AD同期モジュール ADを起点とした同期配信基盤を ユーザデータの加工はID基盤で一元処理 ADから各クラウド間のID同期は 連携アプローチに問わず 原則ADのユーザデータを無加工で 右から左へ渡すようなアプローチで API Gateway製品で置き換えは可能だが コストもそれなりに掛かるので SIした方がよいかどうかとコスト見合いで
  26. 26. IIJが提供するIDaaS (IIJ IDサービス)のご紹介
  27. 27. IIJ IDサービス 連携するサービスへのセキュアなアクセスを実現 連携するサービスに対して、ユーザやロケーションに応じた、適切か つ高度で均一の認証セキュリティを適用できます。 連携サービスへのシングルサインオンを実現 各連携サービスへはシングルサインオンでアクセスできます。 更に、ユーザが利用可能なサービス群へのポータル画面も提供 します。 ゼロアドミンでのID管理 ADからの自動連携機能で、アカウントやグループ情報に加え、 ADのパスワードもIIJ IDサービスに同期させることができま す。ログインポリシーやマイアプリケーション内の制御はグ ループベースで制御できるため、IIJ IDサービスのID管理をAD 内で完結することが可能です。 クラウド型のID管理・認証管理サービス(IDaaS) 28
  28. 28. IIJ IDサービス: デモ 認証デモをご覧いただきます。
  29. 29. IIJ IDサービス: アクセス制限 30 連携するサービスへのセキュアなアクセスを実現 利用するサービスによって認証セキュリティは様々あり、十分な強度を満たしていないことがあります。しかし、利用する サービス群がIIJ IDサービスと連携することで、ユーザごとに適切な高度、かつ、均一の認証セキュリティを適用できます。 多要素認証が必要な場合、ユーザ毎にスマートフォンを用いた「SmartKey認証」、メールを用いた「メールOTP認証」、 または、デバイス証明書を用いた「デバイス証明書認証」を指定できます。 セキュリティ強化/ 多要素認証
  30. 30. IIJ IDサービス: SSO連携 31 連携サービスへのシングルサインオンを実現 IIJ IDサービスはSAML 2.0、および、OpenID Connect 1.0に対応。各サービスへシングルサインオンでアクセスできます。 また、ユーザが利用可能なサービス群へのポータル画面も提供します。 認証管理 (Federation)
  31. 31. IIJ IDサービス: ID管理 32 ゼロアドミンでのID管理 ADからの自動連携機能で、アカウントやグループ情報に加え、ADのパスワードもIIJ IDサービスに同期させることができます。 IIJ IDサービス内のログインポリシーやマイアプリケーションの制御はグループベースで制御できるため、IIJ IDサービスのID 管理をAD内で完結することが可能です。 ※ 連携サービスにはOffice 365(Azure AD)経由、または、SCIMベースでID管理する機能を提供。 ID管理
  32. 32. IIJ IDサービス: 価格体系 33 メニュー 内容 初期費用 月額費用 基本機能 • IIJ各種サービスとの連携 (順次追加予定) • ID管理 (AD/LDAP/Azure ADからの自動連携機能も含む) • アクセス制限 • カスタムパスワードポリシー • 監査機能 • セルフサービス機能 • ブランディングカスタマイズ 0円 0円/ID オプション 外部サービス連携オプション • SAML 2.0/OpenID Connect 1.0準拠の 連携サービスとのSSO連携 (IIJ IDサービス→連携サービス方向のSSO連携) • 外部IdP認証 (外部IdP→IIJ IDサービス方向のSSO連携) • Azure AD/SCIMサーバへのID連携 (IIJ IDサービス→Azure AD/SCIMサーバ方向のID連携) • Webリンクアプリケーション機能 ※ 接続できるサービス数に制約はありません。 0円 100円/ID 多要素認証オプション • スマートフォンアプリ 「IIJ SmartKey」(無償)を用いたSmartKey認証 • メールOTP認証 • デバイス証明書認証 ※ デバイス証明書は発行するデバイス数には依存せず、ユーザ数にのみ依存します。 ※ 複数の多要素認証を組み合わせてご利用いただいても料金に変更はありません。 0円 100円/ID
  33. 33. 本書には、株式会社インターネットイニシアティブに権利の帰属する秘密情報が含まれて います。本書の著作権は、当社に帰属し、日本の著作権法及び国際条約により保護されて おり、著作権者の事前の書面による許諾がなければ、複製・翻案・公衆送信等できません。 本書に掲載されている商品名、会社名等は各会社の商号、商標または登録商標です。文中 では™、®マークは表示しておりません。本サービスの仕様、及び本書に記載されている 事柄は、将来予告なしに変更することがあります。 ご清聴ありがとうございました

×