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

2. マルチクラウド時代に求められる
ID＆シングル・サインオン（SSO）基盤とは？
ネットワーク本部
渡辺 尚徳

3. クラウドサービス利用にあたっての
現状と潜在リスクと課題

4. 多くの企業に利用されているクラウド
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割の企業が新規システムの構築時にクラウドを検討。
クラウドファーストの浸透が顕著

5. マルチクラウド利用の時代に
クラウドとオンプレミスのシームレスな連携を要求
ID管理者はプロバイダー兼ブローカ（IDブローカ）としての
振る舞いが必要
クラウドの適用範囲が広がり、マルチクラウド利用が当たり前の時代になりつつあります。
結果、より多くのオンプレミスとクラウドの連携やクラウドとクラウド間の連携が今後求められてきます。
今後
現在
過去
オンプレミスのみの利用
• クラウドとの連携なし
限定的なクラウドの利用
• 情報系としての利用
• 少数のクラウドとの連携
積極的なクラウドの利用
• 基盤系としての利用
• 多数のクラウドとの連携
ユーザ
ID管理者
オンプレミス
プライベート
クラウド
パブリック
クラウド
ハイブリッド
クラウド
5

6. 課題&潜在リスク① ID&SSO基盤の対応
ID/SSO基盤によりオンプレミスは最適化されたが、
クラウドサービスの利用が進み、マルチクラウドへの適用が課題に
ユーザ
ID管理者
HR
CSVID基盤
構築/運用コストが高い
お客様環境
マルチクラウドの時代へ
各クラウドの
ID更新を
個別で実施
各クラウドごとに
異なるID/PWでの
ログインが必要
Active Directory
LDAP
RDB
ポータルサーバ
グループウェア
ERP
SSO基盤 SSOレポジトリ
オンプレミスシステムの
各Webサイトに1つのIDで
シングルサインオン
オンプレミスシステムの
ID管理フローの一元化
クラウドへの対応が難しい
6

7. 課題&潜在リスク② ID/PW漏洩
実在の組織や社員を
語るメールを送信
本文に記載されたURLを踏むと
巧妙な偽サイトに誘導
攻撃者
ユーザ
攻撃の起点になりやすいメールサービスに対して、
ビジネスメール詐欺やフィッシング詐欺が仕掛けられ、
ID/PWが漏洩する事例が多く報告されています。
7
メールのID/PWなどの入力を要求させ、
ユーザのID/PWを奪取
Office 365 の画面などに似せた
巧妙なフィッシングサイト

8. 課題&潜在リスク③ 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

9. 課題&潜在リスク④ 法規制（個人情報保護）
日本国内での運用だけ考えても、ID/パスワードだけでの情報保護の限界を踏まえ、PCI DSSや経済産
業省のクラウドセキュリティガイドラインでも多要素認証の導入の必要性を謳っています。
PCI DSS v3.2
要件 8: コンピュータにアクセスできる各ユーザに一意の ID を割り当てる
8.3.1 管理アクセス権限を持つ担当者のすべてのコンソール以外のカード会員データ環境への管理アクセスに多要素認証を組み込む。
注: この要件は、2018年1月31日まではベストプラクティスとみなされ、それ以降は要件になります。
8.3.2 ネットワーク外部からのネットワークへのリモートアクセスすべてに （ユーザと管理者、サポートやメンテナンス用の第三者の
アクセスを含む）多要素認証を組み込む。
経済産業省 「クラウドセキュリティガイドライン活用ブック」より
クラウド上のID管理においてはネットワークからの攻撃を受けるため、パスワードの複雑さだけではなく、二要素認証や二段階認証などの単体
のパスワードの強度だけに依存しない対策を行うことが重要です。また、クラウドサービスを選択する際にも、コントロールパネルやユーザ管
理においてこれらの認証機能が選択できるところを選択するのが良い。
9

10. マルチクラウドに求められる
ID&SSO 基盤とは

11. マルチクラウドのID&SSO管理での必要要素
11
認証管理
（Federation）
セキュリティ強化/
多要素認証
ID管理

12. マルチクラウドへの認証管理
12
認証管理
（Federation）
セキュリティ強化/
多要素認証
ID管理

13. オンプレミスにおけるSSO方式（おさらい）
エージェント リバースプロキシ 代理認証＋リバースプロキシ
システム構成
クラウドとの
SSO連携可否
×
• クラウドへのエージェント導入が
不可であるため、クラウドとの連
携方式としては不可
×
• クラウドにも認証機構が存在してい
るため、代理認証との併用が必要
△
• 代理認証を経由してクラウドでの認証が可能
だが、インターネット上へIDとパスワードが
送信されてしまう
既存システムの
変更要否
×
• 既存システムにエージェントを組
み込む必要がある
• ネットワーク構成を変更する必要
が無い
△
• 既存システムの改修が不要
• 必要に応じて、全てのアクセスがリ
バースプロキシを経由するように
ネットワーク構成の変更が必要
△
• 既存システムの改修が不要で、既存システム
にフォーム認証がある場合にも連携可能
• 全てのアクセスが代理認証プロキシを経由す
るようネットワーク構成の変更が必要
大規模システム
への対応
○
• アクセスが各システムに分散され
るため、大規模やトラフィック密
度の高いシステムに最適
△
• アクセスがリバースプロキシに集中
するため、大規模やトラフィック密
度の高いシステムに不向き
△
• アクセスが代理認証プロキシに集中するため、
大規模あるいはトラフィック密度の高いシス
テムに不向き
オンプレミスのSSO方式をそのままクラウドには適用できないため、新しい技術の導入が必要
認証サーバ
WEBシステム
リバースプロキシ
WEBシステム
認証サーバ 代理認証プロキシ
WEBシステム
認証サーバ
エージェント
クラウドとSSOの連携を行うために新しい技術の導入が必要 13

14. 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

15. 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

16. SAMLとは？
ブラウザのオートリダイレクト機能を利用し、クライアント＆各サービスともエージェントレスで、
認証時ID/PW情報を流さないXMLをベースにした標準規格
SSO基盤
（SAML IdP（アイデンティティプロバイダ））
クラウドサービス
（SAML SP（サービスプロバイダ））
① 利用者がクラウドサービスにアクセス
② （事前設定に基づき）
指定されたSSO基盤へ
オートリダイレクト
③ SSO基盤でユーザ認証
クライアントのブラウザ
⑤ ログインを許可
④ （事前設定に基づいた）
オートリダイレクトにて
SAMLアサーションリクエストを添付
お互いのサービスに事前に下記を設定
• お互いのサービスのURL
• お互いのユーザをユニークに紐付ける属性
• 共有鍵
エージェントなどは必要なし
SAML
16

17. 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

18. マルチクラウドへのセキュリティ強化/多要素認証
18
認証管理
（Federation）
セキュリティ強化/
多要素認証
ID管理

19. ID/PWだけでは認証させない仕組みが必要
19
詐欺被害を抑えるには「認証セキュリティ」が重要で、
ID/PW認証+アルファの対策が必要

20. ID/PWの漏洩に対するアプローチ案
20

21. ID/PWの漏洩に対する対策方法
21
※ Office 365での対策例

22. マルチクラウドへのID管理
22
認証管理
（Federation）
セキュリティ強化/
多要素認証
ID管理

23. 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

24. クラウドに対するID管理で考慮した方がいい事
24
ID管理者
HR
CSV
ID基盤
お客様環境
Active Directory
API変換サービス CSV転送サービス
各クラウドサービス側提供
AD同期モジュール
ADを起点とした同期配信基盤を
ユーザデータの加工はID基盤で一元処理
ADから各クラウド間のID同期は
連携アプローチに問わず
原則ADのユーザデータを無加工で
右から左へ渡すようなアプローチで
API Gateway製品で置き換えは可能だが
コストもそれなりに掛かるので
SIした方がよいかどうかとコスト見合いで
現行の対策としてはADを起点とした連携が現実的

25. まとめ: マルチクラウドに求められるSSO管理
25
認証管理
（Federation）
セキュリティ強化/
多要素認証
ID管理
Federation
Federation
Federation

26. まとめ: マルチクラウドに求められるID管理
26
認証管理
（Federation）
セキュリティ強化/
多要素認証
ID管理
ID管理者
HR
CSV
ID基盤
お客様環境
Active Directory
API変換サービス CSV転送サービス
各クラウドサービス側提供
AD同期モジュール
ADを起点とした同期配信基盤を
ユーザデータの加工はID基盤で一元処理
ADから各クラウド間のID同期は
連携アプローチに問わず
原則ADのユーザデータを無加工で
右から左へ渡すようなアプローチで
API Gateway製品で置き換えは可能だが
コストもそれなりに掛かるので
SIした方がよいかどうかとコスト見合いで

27. IIJが提供するIDaaS
(IIJ IDサービス)のご紹介

28. IIJ IDサービス
連携するサービスへのセキュアなアクセスを実現
連携するサービスに対して、ユーザやロケーションに応じた、適切か
つ高度で均一の認証セキュリティを適用できます。
連携サービスへのシングルサインオンを実現
各連携サービスへはシングルサインオンでアクセスできます。
更に、ユーザが利用可能なサービス群へのポータル画面も提供
します。
ゼロアドミンでのID管理
ADからの自動連携機能で、アカウントやグループ情報に加え、
ADのパスワードもIIJ IDサービスに同期させることができま
す。ログインポリシーやマイアプリケーション内の制御はグ
ループベースで制御できるため、IIJ IDサービスのID管理をAD
内で完結することが可能です。
クラウド型のID管理・認証管理サービス（IDaaS）
28

29. IIJ IDサービス: デモ
認証デモをご覧いただきます。

30. IIJ IDサービス: アクセス制限
30
連携するサービスへのセキュアなアクセスを実現
利用するサービスによって認証セキュリティは様々あり、十分な強度を満たしていないことがあります。しかし、利用する
サービス群がIIJ IDサービスと連携することで、ユーザごとに適切な高度、かつ、均一の認証セキュリティを適用できます。
多要素認証が必要な場合、ユーザ毎にスマートフォンを用いた「SmartKey認証」、メールを用いた「メールOTP認証」、
または、デバイス証明書を用いた「デバイス証明書認証」を指定できます。
セキュリティ強化/
多要素認証

31. IIJ IDサービス: SSO連携
31
連携サービスへのシングルサインオンを実現
IIJ IDサービスはSAML 2.0、および、OpenID Connect 1.0に対応。各サービスへシングルサインオンでアクセスできます。
また、ユーザが利用可能なサービス群へのポータル画面も提供します。
認証管理
（Federation）

32. IIJ IDサービス: ID管理
32
ゼロアドミンでのID管理
ADからの自動連携機能で、アカウントやグループ情報に加え、ADのパスワードもIIJ IDサービスに同期させることができます。
IIJ IDサービス内のログインポリシーやマイアプリケーションの制御はグループベースで制御できるため、IIJ IDサービスのID
管理をAD内で完結することが可能です。
※ 連携サービスにはOffice 365（Azure AD）経由、または、SCIMベースでID管理する機能を提供。
ID管理

33. 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

34. 本書には、株式会社インターネットイニシアティブに権利の帰属する秘密情報が含まれて
います。本書の著作権は、当社に帰属し、日本の著作権法及び国際条約により保護されて
おり、著作権者の事前の書面による許諾がなければ、複製・翻案・公衆送信等できません。
本書に掲載されている商品名、会社名等は各会社の商号、商標または登録商標です。文中
では™、®マークは表示しておりません。本サービスの仕様、及び本書に記載されている
事柄は、将来予告なしに変更することがあります。
ご清聴ありがとうございました