IIJにおける統合認証の取り組み

齋藤 透 (@tsaito20)
株式会社インターネットイニシアティブ
プロダクト本部

自己紹介
 齋藤 透 (さいとう とおる)
 所属

 株式会社インターネットイニシアティブ プロダクト本部 プロダクト開発部
マネジメントサービス課長
 2002年度 新卒入社、一貫してサービス/プロダクトの開発業務に従事

 職務内容 法人向け高機能ルータ「SEIL」(ザイル)シリーズの開発
 ルータのゼロコンフィグ、集中管理サービス「SMF(SEIL ManagementFramework)」の開発、運用
 中小法人向けオンライン販売基盤「LaIT」(ライト)の基盤開発、運用
 2012年より統合認証プロジェクト参画‐2‐

本日お話する内容について
本日お話する内容には、IIJとしての狙いや課題についての言及が含まれますが、あくまで私自身の個人的な見解であり、必ずしもIIJの立場、戦略、意見を代弁するものではありません。ご注意ください。

‐3‐

本日のテーマ今後、認証やID管理といった技術はますます重要になっていくIIJも真面目にIDに取り組んでいきたい、と考えていますこんな課題を考えているので皆さんに聞いていただきたいレガシーてんこもりなISPで統合認証って結構大変…
エンタープライズ領域においてIDaaS普及のために何が必要か？
IDaaSビジネス、ってほんとに成立しうるのか？

何かヒントになるような気づきがあれば幸いです 技術的な話は少なめです。。すみません。

‐4‐

お話する内容

IIJにおけるIDの現状と課題
認証関連の一般動向
IIJの取り組み
IIJの取り組み(技術編)今後の課題とまとめ‐5‐

IIJにおけるIDの現状と課題‐6‐インターネットといえばIIJ…ですが設立当初
1995年度

米国ナスダック上場時
1999年度

現在（東証一部）
2012年度5%

24.2％ 20.7％
100%

38%

57%

20.6％

17.9％

16.6％

インターネット接続サービス

WANサービス

アウトソーシングサービス

ネットワークシステム構築（機器販売含む）

ネットワークシステム運用保守‐7‐

現在の事業内容‐8‐

IIJサービスオンライン「2003」‐9‐アカウント 運用管理担当者に払い出されるアカウント
 マスターID» SA1234567 のような形式» サービスオンラインのログインに利用 回線サービスやDNSサービスはこれだけで完結。エンドユーザは直接的にはIIJを使っていることすら認識しない。

 メール系サービス用アカウント

 メールアドレス形式で払い出されるアカウント

 ファイルシェアサービス系アカウント

 任意のユーザ名で払い出されるアカウント

 ホスティングサービス系アカウント

 マスターIDを共有するものやftp用アカウントとして任意のアカウントを登録できるものなど色々

サービス毎にアカウント体系やポリシーが混在..
‐ 10 ‐IIJならではのアカウントも
 PPPoEアカウント
 RADIUS

 メールアカウント
 POP
 SMTP IMAP

 ネットワーク機器

 ルータ、スイッチ等» コンソールログイン» VPN 認証

 ホスティング

 サーバアカウント
 特権ID (Root) ftp, ssh 等‐ 11 ‐IIJの現状

歴史
インターネット草創期から存在しているサービスがまだ一部現役
INSダイヤルアップ, IIJ4U など

サービスの多様性
Webサービスしかなければ色々楽だけど、、アカウントの多様性
残念ながら統合されているとは言い難い状況、、
システム的にも結合が難しい‐ 12 ‐

認証関連の一般動向‐ 13 ‐

ターゲット分類
個人、コンシューマ• Facebook, Twitter, Yahoo! Japan, ...
ここを中心に法人、エンタープライズ• Salesforce, Windows Azure AD, PingIdentity, ...
政府・公共• マイナンバー, 企業番号, ...
学術系• 学認‐ 14 ‐

エンタープライズ市場の特徴
コンシューマ市場との違い(1) ID 情報の管理主体は企業である(2) 業務アプリがID情報を利用する(3) ID情報/認証システムは企業内で利用する‐ 15 ‐

ID情報の管理主体は企業である
 プロビジョニングが必要

 個人が勝手に作ったアカウントではなく、人事などの部署が責任を持って作ることになる 連携する業務システムへの登録(プロビジョニング)も合わせて行う必要がある» 鉄板ソリューションはCSV..

 IDライフサイクルが存在する
 入社、異動、退社
社内IDマスタ

社内システムIdP

人事DB

AD

‐ 16 ‐SaaS

業務アプリがID情報を利用する
 スケジューラ、勤怠管理、CRMなど、、
 Twitter, Dropbox のように「使いたい人だけ登録してください」という訳にはいかない 利用者は予め全員プロビジョニングされている必要がある
 適切な権限管理も必要
 権限管理は属性情報として部署名などの組織情報に強く紐付くことが多い‐ 17 ‐

ID情報/認証システムは企業内で利用する
 ファイアウォールの存在
 外部とのフェデレーションを行う際に、RP→IdPへの通信は制限される
 SAMLは問題無し
 OpenID Connect : Implicit Flow

‐ 18 ‐

エンタープライズにおけるコンシュマライゼーションの流れ 昨年あたりから良く言われ始めた「コンシュマライゼーション」

http://nosurrender.jp/idit2012/program‐ 19 ‐

コンシューマ向けサービスが便利すぎる件
 業務で使うとあまりにも便利なサービス
 Evernote
 Dropbox
 Google Docs Skype 業務で使うとあまりにも便利なデバイス
 スマートフォン タブレット

使わせないようにする仕組み、ではなく、如何に安全に使わせるか、が課題となりつつある
流行のキーワード:
BYOD (Bring Your Own Device), BYOC (Bring Your Own Cloud)MDM (Mobile Device Management), MAM (Mobile Application Management) など‐ 20 ‐

アプリケーションの疎結合化
これまでのアプリケーション
機能追加
機能追加
機能追加
機能追加

機能追加

‐ 21 ‐

アプリケーションの疎結合化
これからのアプリケーション

https://ifttt.com/‐ 22 ‐

キーポイントIdentity の扱いがキーになるAPIを中心にしたエコ・システムの発展

しかし、エンタープライズでの利用には「信頼」モデルの確立が不可欠‐ 23 ‐

トラストフレームワーク
そのIdPは信用できるのか、そのSPは信用できるのか、といった信頼性に対する不安がある
SPは信用できるのか？
不正なデータ利用しないか？

利用者同意に基づくIdentity情報の提供

IdPは信用できるのか？
IdPのデータは正しいのか？

IdP

RP

Identity情報の登録/認証

サービス利用User

何に同意しているか分からない
目的外データ利用されていないか不安

第三者による、Trust (信頼) を保証する仕組みを整備する必要性‐ 24 ‐

トラストフレームワーク
 基本モデル
Policy Maker(ポリシー策定者)
認定
Trust Framework Provider(トラストフレームワーク提供者)

契約

Identity
Provider
認証利用者

認定

監査監査人

LoA
LoP

‐ 25 ‐

契約

Relying
Party
利用エンタープライズID市場の立ち後れぶっちゃけて言うと、、コンシューマや学術系に比べ、IDをコアとしたサービス基盤がまだ立ち上がっていない最強のプロビジョニング「CSV」
最強のフェデレーション「パスワード共有」
なぜ?
IdPがビジネスとして成り立つかどうか不透明サプライチェーン間でのフェデレーションはまだアリだが、利害関係のある企業間でフェデレーションのニーズがそもそも無いレガシーシステムが多すぎて、技術的にも課題が多い» 結局、代理認証が必要になるケースも少なくない

「鶏卵」問題もあるにはありそう‐ 26 ‐IIJの取り組み‐ 27 ‐

クラウド時代におけるキャリアのあるべき姿は？
 ネットワークのコモディティ化
 ネットワークインフラ＞サービス、だった時代が終わりつつある (過去)HTTP/TLSの仕様に合わせてアプリをチューニングする
 (現在)現状のHTTPはだめ、新しいプロトコル作ろうぜ by Google → SPDY

 ビジネスの基盤となるレイヤが上がっている。スイッチやルータだけで商売できていた時代は終わりつつある 若い人の感覚：「インターネット」≒「LINE」

 IIJのビジネスの方向性は大きく舵取りを変えつつある ISPビジネスは one of them
 SI事業、クラウドサービスが大きな柱として育ちつつある さらにこの先は？

‐ 28 ‐

Identityが中心となる時代へ

サービス

サービス

Identity
Internet‐ 29 ‐

サービス

時代背景の整理
今後、扱うべきシステムは増えることはあっても減ることはない
企業のセキュリティ要件はますます厳しくなっていく遅かれ早かれ、日本でもいずれクラウド(SaaS)利用が本格的に浸透していく‐ 30 ‐

お客様が求めている(と思う)こと
 何度も入力（更新）するパスワードを減らしたい！！

 難しい文字列はせいぜい1パターンくらいしか覚えられない。

 ID管理の仕組みがない or 入社時や異動時の登録ミスを無くしたい！
 そもそもキチンとID管理できている会社は企業規模を問わず少ない。

それだけじゃなくて、 セキュリティを強化したい！！

 セキュリティ強化を理由にしないと、SSOだけじゃ予算も出ないしね。。。

もっと言うと、 マルチデバイス対応したい！！

 スマートデバイスでの利用も予め考慮しておかないとまずいよね。

‐ 31 ‐

クラウド時代のEnterprise Identity全体イメージ＜パターン1＞
顧客にAD等がないケース
ログイン

オンライ SSO&プロビ
IDM&ログイン
証跡管理 ンブック
マーク
画面

SAML

IIJサービス /自社業務アプリ
Google, O365,SFDC, WebEx,
Cybozu.com等＜パターン2＞
顧客AD等と連携するケース
ログイン

オンライ SSO&プロビ
IDM&ログイン
ンブック
証跡管理画面マーク

ADSAML同期‐ 32 ‐IIJサービス /自社業務アプリ
Google, O365,SFDC, WebEx,Cybozu.com等

IIJができそうなこと
 国内最古クラスのキャリアISPとして、一応そこそこの大規模運用実績を持っています 保有しているエンドユーザアカウント(メールサービス等)もそこそこあります メイン顧客層は大規模法人顧客。エンタープライズはお得意様です セキュリティ分野の専門家も在籍していますIDaaS、できそうな気がする…!

‐ 33 ‐

ビジネスプラン

「Enterprise Identity Provider」

キャリアの立場で提供する IDaaS (Identity as aService)クラウドにIDを預ける、を実現するフェデレーションを簡単にする、を実現する‐ 34 ‐IIJ ID
 統合認証を実現するためにIIJが管理するID体系
 「IIJ ID」を提供

 メールアドレス形式を基本にする

 ID管理システムとしての必要要件
 マルチテナント対応
 IDライフサイクル管理
 IDプロビジョニング‐ 35 ‐IIJの取り組み(テクノロジー編)‐ 36 ‐システム構成イメージ
 SSO (IdP)：OpenAM (OSSTechカスタマイズ版) を利用
 ID管理システム (IDM)：エクスジェンネットワークス Cloud Identity
Manager Ver2.0 を利用
IIJサービス

SSO

OpenLDAPSAML

プロビジョニング

••
•
•

メール
ホスティングセキュリティ
etc.

他社SaaS
プロビジョニング

IDストア
プロビジョニング••••

Salesforce
CybozuOffice365
etc.

ユーザ企業
AD
社内システム人事マスタ‐ 37 ‐

社内システム全体機能構成イメージ
IIJ ID manager（Cloud Identity Manager)
管理者向け

オペレータ向け

プロビジョニング

テナント管理ユーザ管理(個別)

CSV

サービス管理ユーザ管理(一括)AD

監査/モニタリング
属性管理

エンドユーザ向け
パスワード変更

SCIM
hook script

Authentication/Authorization (OpenAM)

FederationSingle Sign On(SSO)

付加価値SAML

リバースプロキシ方式

多要素認証

OAuth 2.0

代理認証方式

リスクベース認証

OpenID Connect

エージェント方式

セキュリティ

‐ 38 ‐

OpenAM
 選定のポイント

 OSSTech版を利用
 ベースがオープンソースであり、ユーザ数単位でのライセンス費用は発生しない
 何かトラブルがあれば、最終的にソースコードレベルで追いかけられる» ブラックボックスのプロダクトで過去何度も痛い目を見ている» ソースを追いかけるスキルのあるエンジニアもちゃんといる

 標準的なJavaアプリとして実装されており、IIJのサービスホスト構築にあたり親和性が高かった

 IIJとしての機能要件

 各種フェデレーションプロトコルに対応(SAML, OAuth, ...)
 将来的なロードマップとして OpenID Connect などの標準技術への取り組みがあること(OpenAM 11 で実装済)
 レガシーなシステムとのSSO(リバースプロキシ方式)にも対応
 マルチテナント IdP を実現可能‐ 39 ‐

対応する認証フェデレーション方式
 SAML 「SAML is Dead」という話もありますが、、
 そうは言っても、実質的に現時点ではSAMLがベストな選択肢という判断。対応SaaS
サービスの数も多い。
» 海外: Google Apps, Salesforce, Office365 を始めたくさん» 国内: Cybozu を始め徐々に増えつつある 課題は、IdP/SP間の方言問題» 個別にテストしないと安心できない 実装が複雑。デバッグが大変。

 OpenID Connect

 いよいよ 2/26 に最終版がリリースされる見込 エンタープライズ領域での普及はまだこれから、といったところ‐ 40 ‐

マルチテナントの考え方 テナント IDを管理する主体としての企業を１テナントとみなす 1テナント=1 IdP テナント管理者はそのテナント内に限り、IDの管理権限を持つ
 テナントをまたがったIDの参照/検索などができてはいけない‐ 41 ‐

OpenAMの構成
 レルムはIdP毎に用意
 IdP毎に証明書を発行

 使用するLDAPは一つ

 IdP毎にテナントのベースDN以下のデータを検索するように設定する

 テナント追加時は専用スクリプトを用意
 運用上の利点

 テナント毎にIdPを用意するため、柔軟に細かい制御ができる OpenAM, OpenLDAP共にサーバを集約しているため、メンテナンスコストを減らせる

 欠点

 サーバ障害が全顧客に対して波及する» 前段にLVSを置いて冗長化‐ 42 ‐

OpenLDAPの構成
 LDAPのスキーマ定義自体のマルチテナント化が必要。選択肢として以下の方法が考えられる
 (1) １つのDITで管理する
 (2) １つのOpenLDAP内で複数のDITに分ける (3) テナント毎にサーバを分ける テナント追加時に専用のスクリプトを用意
 冗長化は前段にLVSを置き、マルチマスタ構成
 基本は片側にアクセスを寄せておく‐ 43 ‐※ OSSTech 野村様の協力をいただき検討

各管理方法の比較
OpenLDAPサーバ 単体構成
1つのDITで管理

テナント毎にサーバ構築
DIT分割(database分割)

設定ファイル1つのファイルで済む。テナント数が増えると記述内容が増加し、管理コストが増える懸念がある

テナントの数だけ複数存在する。

設定変更

ある程度はテナント毎に異なる設定変更を実施できるが、グローバルオプションはテナント毎に設定できない。

テナント毎に柔軟に設定変更可能

サーバプロセス再起動

設定変更時再起動が必要。1つのテナントのための再起動であっても、全てのテナントに影響する

影響範囲は該当テナントのみに留まる

テナントの追加/削除

LDAPエントリの追加だけであれば再起動は不要
設定変更する場合は再起動必
要

アクセス制御ルール

ある程度自由に設定可能だが、 テナント毎にある程度自由に設定可能
記述が複雑になる

テナント毎に自由に設定可能

ログ

全てのテナントログが同じファイルに出力される

各サーバ毎に分かれる

耐障害性

1つの設定変更ミスなどが全てのテナントに影響する可能性がある

影響はサーバ単位に留まる

バックアップ・リストア

全てのテナントのデータを丸ごとバックアップ/リストアする

テナント(サーバ)毎に可能

アップデート

1台のアップデートで済む

再起動必要

テナント毎に可能

新規にOpenLDAP構築

全てのサーバでアップデートが必要‐ 44 ‐※ OSSTech 野村様資料より抜粋

マルチテナント構成モデル
OpenAM

OpenLDAP
LDAP

SP 1
テナントA
IdP A
SP 2

Users

テナントB
SP 3

IdP B
Users

SP 4

テナントC
IdP C
Users

‐ 45 ‐

運用要件
 サービスの無停止運用が必須

 通常運用においてOpenLDAPやOpenAMの再起動によるサービス停止を避けたい CIM, OpenAM と OpenLDAP間の連携時、OpenLDAP側にACLをかけ、テナントをまたがったオペレーションが発生しないようにケアしておく必要がある
 OpenAM、OpenLDAPのサーバそのものに対しても適切にACLをかけ、顧客情報の漏洩が起こらないような構成にする‐ 46 ‐

Cloud Identity Manager (CIM)について
マルチテナント構成が可能なID管理システム
各種プロビジョニング連携や、ロールに応じた画面制御を柔軟に構成可能

ｸﾗｳﾄﾞ管理者

クラウドサービス利用企業A

顧客管理者
顧客ｵﾍﾟﾚｰﾀ

顧客管理者用ポータル
・企業Aのオペレータ管理

顧客情報DB

クラウド管理者用ポータル
・顧客情報管理・クラウドサービス管理

顧客オペレータ用ポータル
・企業AのID管理

利用者用ポータル
・本人のパスワード/プロファイル管理

プロビジョニング
・ID情報連携

IDストア‐ 47 ‐CSVADLDAPCIMへの期待 柔軟なライセンス体系

 他社プロダクトと比較しても充分に低価格なライセンス体系
 大量のIDを今後扱っていく上での安心感

 LDAP Manager で培ったノウハウ 日本市場独自のワークフローや実際の業務でのハマリどころを熟知。きめの細かい制御が可能
 IDaaSビジネスやSCIMへの展開など、将来のビジョンもしっかりと持っている

 権限管理、セキュリティ対策

 お客様が安心してIDを預けられるような仕組みの提供
 クラウド管理者(IIJ)とテナント管理者(お客様)間の権限分離を実現

 実装方針について細部にわたる要望を議論できる
 IIJ都合の要件も含めて柔軟に実装対応してもらえる 会社が近いのもメリット

‐ 48 ‐

CIM 3.0 (2014年10月リリース予定)※ Exgen 江川様 より情報提供①操作モニタリング・顧客管理者はオペレータのメンテナンス処理結果をモニタリングすることができるようになります。
・顧客管理者がクラウド事業者に対してメテナンス用のオペレータIDを付与した場合は、クラウド事業者にとってはサービスの透明性を説明する場合の裏付けデータとなります。
②顧客オペレータの管理権限制御
・顧客オペレータが管理できる対象をグループ化し、メンテナンス範囲を設定することができるようになります。
・顧客オペレータの操作権限(参照、編集等)を設定することができるようになります。

‐ 49 ‐

CIM 3.0 (2014年10月リリース予定)※ Exgen 江川様 より情報提供③APIの公開
・外部からCIMを実行することができるようになります。
・プロトコルはSCIMを利用する予定です。
・以下の操作が可能です。
1.顧客情報のメンテナンス
2.リソース基本情報のメンテナンス
3.利用者情報のメテナンス④グループ情報メンテナンス
・IDストアでグループ情報を管理することができるようになります。
⑤コネクターの追加
・JDBCコネクタ
・LDAPグループコネクタ
・ADグループコネクタ‐ 50 ‐

CIM スクリーンショット
クラウド管理ポータル/顧客情報一覧

オペレータポータル/ユーザ情報一覧

顧客管理ポータル/顧客情報参照

利用者ポータル/パスワード変更‐ 51 ‐

今後の課題とまとめ‐ 52 ‐

素朴な疑問 IDを預けるとして、どれだけお金を払ってくれるのか？
 お金をもらえそうなポイント

 多要素認証による付加価値 フェデレーション先のRP毎に発生する「SSO課金」
 プロビジョニング先のRP毎に発生する「プロビジョニング課金」» オンプレADなどは個別にVPNを構築するなどそれなりに費用もかかる 海外系では、「IDaaS専業」なサービスも出ている
 Okta、OneLogin、PingOne

 国内も徐々に Cloud Gate, EINS/IAMなど

 とはいえ、基本はキラーとなるコンテンツがあった上でのID連携がまだまだメジャー‐ 53 ‐

フェデレーションの広がりが必要 エンタープライズ領域のSaaS系サービスでID連携の機運の高まりは？
 単純な鶏卵問題？
 トラストフレームワークの不在？
 OpenIDファウンデーション・ジャパン, JNSAの取り組みも進行中

http://www.openid.or.jp/news/2013/12/openid-openid-connectscim.html
SCIM, OpenID Connect 等標準プロトコルもようやく出そろいつつある状況。
今後の展開を期待したい‐ 54 ‐

システム上の課題
 各システム間の結合に手動オペレーションが介在してしまう いちいちGUIで操作していたのでは非効率、かつミスを誘発 APIによる処理自動化が必要
 CIMは今後実装予定(Ver3.0)。

 OpenAMもAPIは用意されていることはいるが、まだ未検証。
 現状では ssoadm を使って自動化しようとしているが若干微妙。。

» 若干作りが甘い雰囲気。色々とエラーが出てハマる。
» テナント追加用のXML設定ファイルを流し込むことになるが、作るのがかなり大変。

 複数のIdP経由でアクセスしてくる状況の中で、SPの実装はどうあるべきか？

 IIJのサービス(基本はマルチテナント対応)自体も今後どう対応していくか、検討が必要
 ログイン画面でIdPを選択させる必要がある？もしくはvirtual hostでログイン画面自体を複数用意する？

‐ 55 ‐

人材！(切実) IIJでは優秀なIDエンジニアを募集しています！

‐ 56 ‐

ご静聴ありがとうございました‐ 57 ‐