最新ＸＭＬセキュリティ技術概要 ドラフト版 2005年12月15日 XMLコンソーシアム セキュリティ部会 横溝 良和 （キヤノン株式会社） 山根　利夫 （株式会社日立製作所） 中山 弘二郎 （株式会社日立製作所） 西村利浩 （富士通株式会社） ドラフト版

アジェンダ XML Security関連規格の調査 SOX法対策とアクセス制御 XACML v2.0の概要 Webサービスポリシー概要 WS-Trust概要

2005年12月15日 XMLコンソーシアム セキュリティ部会 横溝良和 （キヤノン株式会社） XML Security関連規格の調査 2005年12月15日 XMLコンソーシアム セキュリティ部会 横溝良和 （キヤノン株式会社）

WS-Security（WSS）の目的 Webサービスをセキュアにするために、その基本プロトコルであるSOAPを機能拡張する標準（WSS）を作り、End-to-Endの完全性と秘匿性を実現する。 Webサービスのメッセージ通信が、複数のポイントを経由して行われる場合でも、セキュアな通信サービスが確保される。 既存のセキュリティ技術を統一的に使う仕組みを提供する。 幅広いセキュリティ・モデルのサポート 複数のセキュリティ・トークン形式 複数の信頼ドメイン 複数の署名形式 複数の暗号技術 2005.4.27Y.Yokomizo

SSLとWSSの違い SSL：Point-to-Point ? WSS：End-to-End SSL WS-Security トランスポート層のセキュリティ WS中継者から先のセキュリティが不明 End 何も見えない End SSL ? 利用者 中継サーバ Webサーバ （ショッピングサイト等） （想定外） WSS：End-to-End メッセージ・コンテンツのセキュリティ 中継者のセキュリティ度に非依存 End 必要な部分は見える End WS-Security 利用者 中継サーバ Webサーバ （サービス統合サーバ） サービス・ユニット提供者 参考： 岡村和英著「Webサービスのセキュリティ」

SSLの利用例 H 認証局 ホテル 多分SSL SSLあり 旅行代理店 鉄道 航空機 SSLなし レンタカー 個別システム 中身が全部 インターネット 中身が全部 見られる 認証局 SSLあり 旅行代理店から先の通信のセキュリティが保証されない。同代理店に、全ての情報が見られてしまう。 2005.4.27Y.Yokomizo

WSSの利用例 H 認証局 ホテル 旅行代理店 鉄道 航空機 レンタカー End-to-End セキュリティ WSパッケージ 必要なデーター ANA JR ホテル AVIS \125,000 航空機 WSパッケージ 必要なデーター のみ閲覧 レンタカー 旅行代理店から先の通信のセキュリティが保証され、同代理店には、必要最小限の情報しか開示しなくて良い。 2005.4.27Y.Yokomizo

SAMLの利用例 H 認証局 ホテル予約 列車予約 航空機 レンタカー ユーザ 認証 再サインオン 不要 シングルサインオン ユーザー認証情報 認証局 シングルサインオン 一度認証されれば、他の関連サービスは認証無しで利用できる。 2005.4.27Y.Yokomizo

IBM＋Microsoftの共同提案（2002.4.7） 「Webサービスのセキュリティ: アーキテクチャとロードマップの提案」 SOAP基盤 WS-Security WS-Trust WS-Privacy WS-Policy WS-Secure Conversation WS-Federation WS- Authorization IBM Microsoft W3C OASIS 2004.4 WS-Security SOAPメッセージへの署名ヘッダ、暗号化ヘッダ、セキュリティ トークン添付方法 WS-Policy 中間ノードやエンドポイントでのセキュリティ ポリシーの権限や制約の記述 WS-Trust Webサービスを安全に相互運用する為の信頼モデルのフレームワーク WS-Privacy プライバシーの設定、実践ステートメントを提示する方法のモデル WS-SecureConversation セキュリティ コンテキストの交換、セッション鍵確立と派生などの、メッセージ交換を管理、認証する方法 WS-Federation アイデンティティの連合など、異種の連合された環境における信頼関係の管理と仲介の方法について WS-Authorization 認可データや認可ポリシーを管理する方法 WS-SecurityはOASISの標準になった 引用文献： IBM Corporation と Microsoft Corporation 共著によるホワイト ペーパー

OASIS WS-Security規格群（2005.5） Token Profile Kerberos SOAP基盤 WSS SOAP Message Security WSS-X.509 Token profile WSS-Username WSS-SAML WSS-REL W3C OASIS Attachment Profile SOAP with OASIS 2004.5 WS-SecurityはOASISの標準になった 2005.4.27Y.Yokomizo

規格としての位置付け XML Encryption SOAP WSDL UDDI WS Security Web Service基本規格 XML Signature XML Encryption SOAP WSDL UDDI Extensibility Model WS Security X.509 T-Profile Username SAML REL Web Service基本規格 トークン プロファイル群 Kerberos ITU MPEG-21 IETF セキュリティ統合規格 W3C OASIS ユーザ名 パスワード XML Security規格 トークン：認証タグ、代用通貨 2005.4.27Y.Yokomizo

（SOAP Message Security） セキュリティ規格のマップ 指紋、声門、虹彩認証 ContentGuard OASIS シングルサインオン・サービス 利用 XCBF Token Profile XrML REL Token Profile Liberty Alliance OASIS ISO REL 利用 権利辞書 認証 利用 利用 Security Assertion Markup Language Web Service Security （SOAP Message Security） OASIS SAML Token Profile アクセス権制御 シングルサインオン アクセス権 IBM, MS, Verisign WS Security SAML XACML OASIS Sun→OASIS 署名 暗号化 鍵・認証 ポリシー 認証情報 鍵・認証 公開鍵証明書 代替？ XML Signature XML Encryption X.509 Certificate Token Profile SOAP W3C OASIS RPC W3C Canonical XML AES X.509 WSDL W3C NIST ITU W3C XML正規化 C14n 暗号 SSL/TLS UDDI IETF W3C メッセージ・プロトコル Secure Socket layer WS３点セット 場面で 使い分け？ Kerberos Token Profile 鍵管理サービス MIT IETF Kerberos XKMS W3C 暗号によるユーザ認証方式 2005.4.27Y.Yokomizo

Liberty AllienceとOASISの関係 SAMLとLiberty ID-FF, ID-WSFの関係 OASIS SAML 1.0 (2002年5月) SAML 1.1 (2003年5月) SAML 2.0 (2005年1月) 統合 拡張 拡張 ID-FF 1.0 (2002年7月) ID-FF 1.1 (2003年1月) ID-FF 1.2 (2003年10月) 参照 参照 Liberty 参照 ID-WSF 1.0 (2003年11月) ID-WSF 1.1 (2005年3月) ID-WSF 2.0 (策定中) 引用：XMLコンソーシアム主催LibertyAlliance講演資料を追加修正 Liberty Allianceは、「シングル・サインオン」を主要な応用事例とする、ID（アイデンティティ）管理の仕組みを標準化している標準化団体である。 Libertyは、OASISのSAML 1.0をベースに、ID-FF (Identity Federation Framework)を開発したが、ID-FF 1.2の段階で仕様をSAML 2.0に組み入れ、標準化作業はOASISに移管した。一方、ID-WSF (Web Service Framework)とID-SIS (Service Interface Specifications) については引き続きLiberty Allianceが開発を進めるという。ID管理アーキテクチャーは、オープンな連携型の分散ID管理手法を提唱している。アイデンティティ連携（ID-FF）とは、アカウントのサービス間連携とシングルサインオン（SSO）の事である。テストにより互換性が確認された製品には、「互換性認証ロゴ」の表示を認めるという。動作環境はWebサービスのSSOを対象とする。この分野での「ディスカバリーサービス」とは、個人情報のディスカバリーの事である。

2005年12月15日 XMLコンソーシアム セキュリティ部会 山根 利夫 （株）日立製作所 SOX法対策とｱｸｾｽ制御 XACML v2.0の概要 eXtensible Access Control Markup Language OASIS Standard, 1 Feb 2005 2005年12月15日 XMLコンソーシアム セキュリティ部会 山根　利夫 （株）日立製作所

アジェンダ 全体統制としてのｱｸｾｽ制御 ﾛｰﾙﾍﾞｰｽｱｸｾｽ制御 XACMLの概要 V2.0の強化点と製品化状況

1. 全体統制としてのｱｸｾｽ制御 「職務分離」と「ｱｸｾｽ制御」は、SOX法対応に於いて、ｼｽﾃﾑを保障する「IT全体統制」 ｼｽﾃﾑへ利用者を登録する方式での問題点 ｼｽﾃﾑ毎／職務毎の利用者登録 充分に複雑なﾊﾟｽﾜｰﾄﾞ／定期的なﾊﾟｽﾜｰﾄﾞ変更 退職、職務変更等に対する保守 IT全体統制としてのﾛｰﾙﾍﾞｰｽｱｸｾｽ制御 利用者認証とｱｸｾｽ制御の分離 職位等、利用者の属性／役割（ロｰﾙ）による 　　　自動的なｱｸｾｽ権の保守　

2. ﾛｰﾙﾍﾞｰｽｱｸｾｽ制御：RBAC Role-Based Access Control ANSI INCITS 359-2004. 静的な割当に対する 職務分離の強制 ﾛｰﾙ割当 ﾛｰﾙ階層 認証 ﾛｰﾙへのｱｸｾｽ 　許可割当 対象 利用者 ﾛｰﾙ 操作 ｾｯｼｮﾝ生成 ｱｸｾｽ許可 利用形態（セッション）に よる動的な割当に対する 職務分離の強制 セッション

PEP:Policy Enforcement Point 3. XACMLの概要 大組織では「利用者」と「ﾛｰﾙ」の関連管理が膨大 XACMLでは、組織管理上の既存の「属性」情報を活用 ｱｸｾｽ制御 ﾎﾟﾘｼｰ 属性に対するﾎﾟﾘｼｰ によるｱｸｾｽ許可 ﾎﾟﾘｼｰ階層 認証 ﾘｿｰｽ 主体 属性 PEP 動作 ｱｸｾｽ許可 属性の割当は XACMLの範囲外 PEP:Policy Enforcement Point

3.1 XACMLの位置付け 認証 SAML 制御 ｱｸｾｽ PEP ﾘｿｰｽ 要求者 判断 ｱｸｾｽ制御 PDP ﾎﾟﾘｼｰ XACML PDP: Policy Decision Pont SAML: Security Assertion Markup Language WS-TRUST: WEB Service Trust 認証 認証 ｱｻｰｼｮﾝ SAML 制御 WSﾘｸｴｽﾄ ｱｸｾｽ 要求者 PEP ﾘｿｰｽ ｾｷｭﾘﾃｨﾄｰｸﾝ 認証 ｱｻｰｼｮﾝ WSﾎﾟﾘｼｰ (分散型) 承認 ｱｻｰｼｮﾝ WS-TRUST 判断 PDP ｱｸｾｽ制御 ﾎﾟﾘｼｰ XACML 属性 ｱｻｰｼｮﾝ WS-TRUST 関連定義 職務分離 RBAC 主体⇔属性

3.2 XACMLのﾃﾞｰﾀﾌﾛｰ詳細 XACMLのｽｺｰﾌﾟ PIP 要求者 責務ｻｰﾋﾞｽ PDP ｺﾝﾃｷｽﾄ ﾘｿｰｽ 2.ｱｸｾｽ要求 PEP ﾎﾟﾘｼｰ実行ﾎﾟｲﾝﾄ 13.責務 要求者 責務ｻｰﾋﾞｽ XACMLのｽｺｰﾌﾟ 3.要求 12.応答 ﾘｿｰｽ DB 4.要求通知 9.ﾘｿｰｽ 　ｺﾝﾃｷｽﾄ 　　　PDP ﾎﾟﾘｼｰ判定ﾎﾟｲﾝﾄ 5.属性検索 ｺﾝﾃｷｽﾄ ﾊﾝﾄﾞﾗｰ ﾘｿｰｽ 10.属性 11.応答 ｺﾝﾃｷｽﾄ 6.属性検索 8.属性 1.ﾎﾟﾘｼｰ 　　　PIP ﾎﾟﾘｼｰ情報ﾎﾟｲﾝﾄ 7c. 属性 7b. 属性 ﾎﾟﾘｼｰDB PAP ﾎﾟﾘｼｰ管理ﾎﾟｲﾝﾄ 7a. 属性 　　属性DB 主体 環境

3.3 ポリシー定義例 何れかのruleで否なら不許可 ｱｸｾｽを許可する roleがadministratorで <Policy PolicyId=“Policy1” RuleCombiningAlgID=“Deny-Override”> <Rule RuleID=“Rule1” Effect=Permit> <Target> <Subjects> <Subject> 　　　　　　　　　　　　　<SubjectMatch MatchId=“function:string-match”> <SubjectAttributeDesignatir AttributeId=“identifier:subject:role”/> <AttributeValue>administrator</AttributeValue> </Subject> </Subjects> <Actions> <Action> <ActionMatch ActionMatchId=“function:string-equal”> <TargetAttributeDesignator AttributeId=“urn:xx:target:action”/> <AttributeValue>read</AttributeValue> </ActionMatch> </Action> </Actions> </Target> </Rule> : </Policy> 何れかのruleで否なら不許可 ｱｸｾｽを許可する roleがadministratorで actionがreadの場合

4. V2.0の強化点と製品化状況 V2.0での主な強化点 製品化状況 プロファイルの整備（SAML,Digital Signature，LDAP 等） ﾌﾟﾗｲﾊﾞｼｰポリシｰ対応 複数ﾘｿｰｽ、複数の属性値対応 製品化状況 SUN MicroSystems ‘０５／1　SUNXACMLでXACMLv2.0をサポート済み。 ORACLE 　　買収したOblix製品をﾍﾞｰｽに、Identity Managementで 　　’06半ばにXACMLをサポート予定。

付録1 ﾎﾟﾘｼｰ言語仕様 PolicySet PolicyCombining Algolothm Target Policy 付録1　 ﾎﾟﾘｼｰ言語仕様 PolicySet PolicyCombining Algolothm Target Policy Obligation "send-mail" PolicyCombining Algolothm Subject Resource Action Environment "bs@si- mpsons .com" "file:Bart- Simpson" "read" "current-date" :Deny-overrides :Permit-overrides :First-applicable :Only-one-applicable Rule Condition Effect :Permit :Deny “string-equal" "permit"

Webサービスポリシー概要 （WS-Policy, WS-PolicyAttachment, WS-SecurityPolicy） 2005年12月15日 XMLコンソーシアム セキュリティ部会 中山 弘二郎 （株式会社 日立製作所）

Webサービスの相互接続性向上が期待できる 例１） WebサービスＡを利用するためには、SOAPリクエストに署名がされていなければならない 例２） WebサービスBはAESアルゴリズムによる暗号化をサポートしている WSDLでは記述されないが、Webサービスを利用するためには必要な情報 ポリシーの利用例 Webサービスの要件や機能をポリシーとして記述し公開 クライアントは、送信メッセージがポリシーを満たすように処理 Webサービスは、受信メッセージがポリシーを満たしているか検証 ポリシーの標準仕様を策定することで、 Webサービスの相互接続性向上が期待できる SOAP：Simple Object Access Protocol　　AES：Advanced Encryption Standard WSDL：Web Services Description Language

ポリシー関連仕様 WS-SecurityPolicy （2005.7） WS-SecurityPolicy （2005.7） セキュリティAssertion リライアビリティ Assertion WS-SecurityPolicy （2005.7） WS-SecurityPolicy （2005.7） WS-RM Policy （2005.2） 個々の要件・機能 （Assertion）の記述 ・・・ WS-Policy （2004.9） WS-Policy （2004.9） ポリシー（Assertionの集合）のフレームワーク WS-PolicyAttachement （2004.9） WS-PolicyAttachement （2004.9） ポリシーとWebサービスの関連付け ： OASISに提出済みの仕様 （ ）内は最新版の仕様書の公開月 ： 標準化団体未提出の仕様 WS-RM ： WS-ReliableMessaging

WS-SecurityPolicy概要 WS-SecurityPolicyとは Webサービスのセキュリティに関するAssertionの記述方法を規定した仕様 WS-Security、WS-Trust、WS-SecureConversation、トランスポートレベルセキュリティに関するAssertionの記述方法を規定 Assertionの例 SOAPボディの秘匿性が確保されていなければならない <sp:EncryptedParts> <sp:Body/> </sp:EncryptedParts> メッセージには常にUsernameTokenが含まれていなければならない <sp:UsernameToken sp:IncludeToken=".../IncludeToken/Always" />

WS-Policy概要 WS-Policyは、ポリシー表記のフレームワークを規定した仕様 ポリシー表記の例 <wsp:Policy> <wsp:ExactlyOne> </wsp:ExactlyOne> </wsp:Policy> Policy Expression ポリシーの表記。Alternativeの集合。ポリシーを満たすには、下位のAlternativeのどれか一つを満たす必要がある <wsp:All> </wsp:All> Assertion A Assertion B Policy Alternative Policy Alternative Assertionの集合。Alternativeを満たすには、下位のAssertionをすべて満たす必要がある <wsp:All> </wsp:All> Assertion C Policy Assertion Policy Assertion Policy Assertion 個々の要件や機能の表記。Assertionのスキーマは別仕様で規定する ※ Normal Formで記述した場合

WS-PolicyAttachment概要 WS-PolicyAttachmentは、ポリシーとWebサービスを関連付ける方法を規定した仕様 WSDLへの関連付けの例 WS-PolicyAttachmentを使っていることを宣言 WSDL <wsdl:definitions> <wsp:UsingPolicy> <wsdl:message wsp:PolicyURIs=“http://example.com/wsp#ABC”　/> ・・・ </wsdl:definition> URIによりポリシーを参照 ポリシー <wsp:Policy xml:base=“http://example.com/wsp” wsu:Id=“ABC”> ... </wsp:policy> ポリシーのURIを定義

まとめ Webサービスのポリシーとは、Webサービスの機能や要件のこと 以下のポリシー関連仕様が提案されている 個々の機能・要件の記述 WS-SecurityPolicy WS-RM Policy ポリシーのフレームワーク WS-Policy ポリシーとWebサービスの関連付け WS-PolicyAttachment 今後、ポリシー仕様が標準化されることで、Webサービスの相互接続性の向上が期待できる

参考文献 WS-Policy WS-PolicyAttachment WS-SecurityPolicy （Web Services Policy Framework） http://msdn.microsoft.com/ws/2004/09/policy/ WS-PolicyAttachment （Web Services Policy Attachment） http://msdn.microsoft.com/ws/2004/09/policyattachment/ WS-SecurityPolicy （Web Services Security Policy Language） http://msdn.microsoft.com/ws/2005/07/ws-security-policy/

2005年12月15日 XMLコンソーシアム セキュリティ部会 西村利浩 （富士通株式会社） WS-Trust概要 2005年12月15日 XMLコンソーシアム セキュリティ部会 西村利浩 （富士通株式会社）

WS-Trust: 経緯 これまでの経緯 初出：IBMとMicrosoftによるホワイトペーパー「Security in a Web Services World: A Proposed Architecture and Roadmap」(2002年4月) 2002年12月にVersion 1.0、2004年5月にVersion 1.1、2005年2月にVersion 1.2 2005年12月～OASIS WS-SX TCで標準化 (「Security in a Web Services World: A Proposed Architecture and Roadmap」より)

WS-SecurityPolicyで記述 WS-Trust: 概要(1) Webサービスの信頼モデル Webサービスは、メッセージを受け取る際に、クレーム(名前、鍵、許可など)の証明を要求できる クレームはセキュリティ・トークンで表される WS-SecurityPolicyで記述 リクエスタ Webサービス ポリシー(例): SAML属性アサーションによる年齢の証明が必要 <sp:IssuedToken ...> <sp:Issuer>...</sp:Issuer> <sp:RequestSecurityTokenTemplate> <wst:TokenType>...SAML:1.1:assertion</wst:TokenType> <wst:Claims ...>...</wst:Claims> </sp:RequestSecurityTokenTemplate> </sp:IssuedToken>

WS-Trust: 概要(2) セキュリティ・トークンはセキュリティ・トークン・サービス(STS)から取得 トークンの要求 トークンの応答 <wst:RequestSecurityToken Context="..."> <wst:TokenType>...SAML:1.1:assertion</wst:TokenType> <wst:RequestType>...Issue</wst:RequestType> ... </wst:RequestSecurityToken> トークンの要求 リクエスタ セキュリティ・ トークン・ サービス トークンの応答 <wst:RequestSecurityTokenResponse Context="..."> <wst:TokenType>...SAML:1.1:assertion</wst:TokenType> <wst:RequestedSecurityToken> <saml:assertion>...</saml:assertion> </wst:RequestedSecurityToken> ... </wst:RequestSecurityTokenResponse>

WS-Trust: 概要(3) トークンを提示しWebサービスを利用 トークンの提示 WS-Security(WSS)を利用 リクエスタ <S:Envelope> <S:Header> <wsse:Security> <saml:assertion>...</saml:assertion> ... </wsse:Security> </S:Header> <S:Body> </S:Body> </S:Envelope>

WS-Trust: 基本プロトコル 要求メッセージ RequestSecurityToken 応答メッセージ RequestSecurityTokenResponse トークンの型を指定 <wst:RequestSecurityToken Context="..."> <wst:TokenType>...</wst:TokenType> <wst:RequestType>...</wst:RequestType> ... </wst:RequestSecurityToken> 要求の型を指定 <wst:RequestSecurityTokenResponse Context="..."> <wst:TokenType>...</wst:TokenType> <wst:RequestedSecurityToken>... </wst:RequestedSecurityToken> ... </wst:RequestSecurityTokenResponse> 返却されるトークン

WS-Trust: 基本的な要求のタイプ 要求のタイプ Issue – 要求において提供/証明されたクレデンシャルに基づいて、(場合によっては新しい証明情報とともに) 新しいトークンが発行される。 Renew – 以前発行された有効期限付きのトークンを提示することにより、 新しい期限で同じトークンが返される。 Cancel – 以前発行されたトークンが必要なくなったとき、トークンをキャンセルし、その利用を終了する。 Validate – 指定されたセキュリティトークンの有効性が評価され、その結果が返される。

WS-Trust: 交渉/チャレンジ 複数メッセージ交換による交渉/チャレンジも許す リクエスタ Web サービス セキュリティ・トークン要求 (RequestSecurityToken) チャレンジ送信 (RequestSecurityTokenResponse) チャレンジに対する返信 (RequestSecurityTokenResponse) セキュリティ・トークン応答 (RequestSecurityTokenResponse)

WS-Trust: まとめ WS-Trustはセキュリティ・トークン・サービスとやりとりするためのプロトコルを規定 基本的な要求のタイプとして、トークンの発行、更新、取り消し、検証を規定 複雑な交渉/チャレンジのための拡張性も保持 OASIS WS-SX TCで仕様の標準化が開始 WS-Trust WS-SecureConversation WS-SecurityPolicy