Wednesday Jul 25, 2007

本当に 「SAML 2.0 が ASP / アウトソーシング方面で地味に広がる」 かも

昨年末に

2007 年はどうなるか. まず, IdM とは 「パッケージをいれればオッケー」 ではなく 「継続的なイニシアチブ」 であることに多くの人が気づく. あと, 「職務分掌徹底のためのアクセス権限管理の大変さ」 がようやく実感されるようになる. 最後に, SAML 2.0 が ASP / アウトソーシング方面で地味に広がる.
IdM ゆく年くる年 - tkudo's weblog about identity management

予測したけど, とりあえず三番目のやつは的中ってことでいいですかね.

(要求仕様のひとつに 「アカウント情報を学内各種情報システムと連携」 という利便性を実現する必要があったが) SAML ベースの Single Sign-On (SSO) API の利用によって実現への確証を得た。(中略) SSO を用いればキャンパス内の全ての IT サービスへの展開をも可能とする。
Google Apps Education Edition の導入事例: 日本大学

Gmailならサーバからサポートまで無料で利用できる上、ライブドアとのID連携機能も容易に構築可能だ。「公開仕様のSAML(Security Assertion Markup Language)に対応しているから、ID連携も当社が開発でき、相手先が作業し終わるのを待つ必要もない」
livedoorメールにGmail採用 「黒字化へ最後の一押し」 - ITmedia News

このまま

  1. Google Apps / Gmail を利用したい企業が増える
  2. 利用する上で, さらに SSO したい企業 (アウトソーサー) は, 自社のアクセス管理 / SSO システムに SAML2 IdP 機能を付加することになる
  3. 結果的に SAML2 IdP 機能を持った企業が増える
  4. それらの企業が, Google Apps / Gmail 以外のサービス・プロバイダ (アウトソーシー) にも 「御社も SAML2 SP 対応してよ (そうすれば自社の SAML2 IdP がさらに活用できるから)」 とリクエストする
  5. それを承けてサービス・プロバイダも自社のサービスに SAML2 SP 機能を付加することになる
  6. 結果的に SAML2 SP 機能を持ったサービス・プロバイダが増える
  7. それらのサービス・プロバイダのサービスを利用したい企業が増える
  8. 2. にもどる

となって, さらに 2. と 3. のあいだに

企業が Sun Java System Access Manager を導入して自社のアクセス管理 / SSO システムを SAML2 IdP 対応にする

加えて 5. と 6. のあいだに

サービス・プロバイダが Sun Java System Federation Manager を導入して自社のサービスを SAML2 SP 対応にする

が入るといいなー.

Friday Oct 13, 2006

Google Apps for Education への ID 連携とプロビジョニング

Google Apps for Education は, こないだの Google 検索アプライアンスの SAML 2.0 対応の話以上におもしろそう.

Google Apps for Educationは、 今年8月に発表された「Google Apps for Your Domain」の派生製品。 (中略) 大きな特徴としては、 ディレクトリ・サービスやシングル・サインオンを利用するためのAPIをセットにしている点である。

 同APIは、標準認証プロトコルSAML(Security Assertion Markup Language) などを利用したシングル・サインオンやREST(Representational State Transfer) ベースのXMLインタフェースをサポートし、ディレクトリ・サービスへの接続が可能になる。

グーグル、教育機関向け「Google Apps」を発表 : ソフトウェア&サービス - Computerworld.jp

この記事ではよくわからないけど, アカウント管理の概要を読む限りでは以下のような機能を備えているっぽい.

  • SAML でいうところのサービス・プロバイダ (SP) になる. つまり, たとえば学内にアイデンティティ・プロバイダ (IdP) として動作可能なアクセス管理システム (例: Sun Java System Access Manager) が既に導入されていれば, 「IdP @ 学校」 と 「SP @ Google」 との間で連携シングル・サインオンができる.
  • REST ベースのユーザ・プロビジョニング API を提供する. つまり, たとえば学内にアイデンティティ・プロビジョニング・システム (例: Sun Java System Identity Manager) が既に導入されていれば, Google Apps for Education 上のアカウントのライフサイクルを学内からシームレスに管理できるようになる. (どうせなら独自 API じゃなくて, SPML のインタフェースを作ってほしいけど...)

ほかのアプリケーション・サービス・プロバイダも, この流れに乗ってくるんじゃないだろうか. そして将来的には, Dynamic Context-Driven Federated Identity Provisioning へと進化してくわけですねー. (← このへん勝手な願望)

Tuesday Aug 29, 2006

グーグルの「作った人が最後まで面倒を見る」は「職責分離」的にはどうなんだろか

ファイザー日本法人の SOX 法対応に関するケース・スタディにこんなことが書いてあった. いわゆる 本番環境において開発スタッフが業務処理をできてしまう ってやつ.

これまでの指摘項目を見ると、SOX法対応のポイントは大きく二つある。 一つは、職務分離の徹底。 (中略) 例えば、「アプリケーション保守は、内容を最も理解している開発者自身が担当したほうが効率的に思えるが、SOX法はこれを許さない」(以下略)。
先進事例に見る経営とIT 〈守る〉

そういえば, グーグルってこのへんどうなんだろ? たしかこんなこと言ってたっけ:

---研究エンジニアと開発,保守エンジニアの区別はないんですか。
リー氏: 区別はありません。作った人が最後まで面倒を見るのが一番効率がいい。考えた人が自分で作って,リリースして,ケア(保守)していく。一段落したらまた次のプロジェクトに取り掛かるというサイクルです。
「ソースコードを見せて,と創業者のラリーとサーゲイは言うんです」---Google アンジェラ・リー氏:ITpro

グーグルって基本的になんでも自前で作る (ように思える) から, きっと財務報告に影響を与えそうなバックオフィス・アプリケーションも内製してたりするんじゃないだろうか? でもそんなとこまで 「作った人が最後まで面倒を見」 てたら, 米国の上場企業の内部統制的には問題あるような...

気になったので, Google Inc. の Form 10-K をざっと読んでみた. とりあえず 2005 年度年次報告書では, 監査法人である Ernst & Young が 「Google Inc. は経営陣のいう通り財務報告に関する内部統制できてたよ」 (超省略 + 超意訳) と報告している.

REPORT OF ERNST & YOUNG LLP,
INDEPENDENT REGISTERED PUBLIC ACCOUNTING FIRM
(中略)
In our opinion, management's assessment that Google Inc. maintained effective internal control over financial reporting as of December 31, 2005, is fairly stated, in all material respects, based on the COSO criteria. Also, in our opinion, Google Inc. maintained, in all material respects, effective internal control over financial reporting as of December 31, 2005, based on the COSO criteria.

For the fiscal year ended December 31, 2005

では, その前の年度にはなにが書いてあるかというと (下線は筆者):

Risks Related to Our Business and Industry
(中略)
We are required to evaluate our internal control over financial reporting under Section 404 of the Sarbanes Oxley Act of 2002, and any adverse results from such evaluation could result in a loss of investor confidence in our financial reports and have an adverse effect on our stock price.
(中略)
We have in the past discovered, and may in the future discover, areas of our internal controls that need improvement. For example, during our 2002 audit, our external auditors brought to our attention a need to increase restrictions on employee access to our advertising system and automate more of our financial processes. The auditors identified these issues together as a ``reportable condition,'' which means that these were matters that in the auditors' judgment could adversely affect our ability to record, process, summarize and report financial data consistent with the assertions of management in the financial statements.

ITEM 9A. CONTROLS AND PROCEDURES
(中略)
Since 2003 we have invested significant resources to comprehensively document and analyze our system of internal control over financial reporting. We have identified areas requiring improvement, and we are in the process of designing enhanced processes and controls to address issues identified through this review. Areas of improvement include streamlining and standardizing our domestic and international billing and other processes, further limiting internal access to certain data systems and continuing to improve coordination and communication across business functions.

Form 10-K for the fiscal year ended December 31, 2004

2002 年度の監査で a need to increase restrictions on employee access to our advertising system (Google の広告システムへの, 社員のアクセス制限を強化する必要性) を指摘されてたとか, 今後改善を要する問題として limiting internal access to certain data systems (データの入っているシステムへの内部からのアクセスの制限) を挙げているところが興味深い. 完全に妄想だけど, もしかしてこれって, システム (AdWords とか?) を 「作った人が最後まで面倒を見」 てたのを注意されたんだったりして.

グーグルの広告システムのアクセス権限不備の真相はわからないけど, いずれにせよ Web 2.0 的な諸々と内部統制とは, 現状いろいろぶつかるところがあるんじゃないかな. たとえば 「perpetual beta における変更管理」 とか, 今後議論すべきネタとして面白そう.

Thursday May 11, 2006

Google 検索アプライアンスの SAML 2.0 対応

Google Search Appliance

へー, Google 検索アプライアンスって SAML 2.0 に対応してるんだ.

要するに、Google Search Applianceの認証SPIはSAML2.0がベースであり、特にそれはBrowser profile である、、ということです。
Google がIdentity と出会ったぁぁ・・・認証SPIはSAML2.0がベース!!

一年半前に SAML 対応アプリケーションをちょっと調べてみたことがあって, そのときには

簡単に言うと, Web SSO システムを経由せずに Web サイトに直接アクセスしたときの SSO は SAML 1.0 / 1.1 の枠組みだけでは実現できないのだが, そのへんはどうしているのだろうか. どうせなら, これを解決する仕組みを定義した Liberty ID-FF や, それを踏襲する SAML 2.0 まで実装してくれたらいいんだけど.
tkudo's weblog: SAML Enabled Web Application System

などという所感をもったんだけど, ようやく SAML 2.0 に対応するアプリケーションが出てきたか. 某 Web 会議アプリケーション・サービス・プロバイダも SAML に対応している (「企業ポータルにログインすることで, 社外 (他ドメイン) の Web 会議 ASP への再ログインが不要になる」 的な使い方) らしいし, いよいよ

しかし保護対象の Web システム側 (アプリケーション・サーバに限らず, 例えば独自アーキテクチャのグループウェアとか Web メールとかも含めて) が SAML に対応し, 各システムがエージェント無しに直接認証・認可情報を扱えるようになると話は変わってくる. Web SSO 製品はエージェントを開発しなくても良くなるし, Web システム・ベンダは Web SSO 製品に縛られることがなくなる.
tkudo's weblog: SAML Enabled Web Application System

ような時代になりつつあるのかなあ.

で下道さんがポイントしてた Google Authentication/Authorization for Enterprise SPI Guide をざっと読んでみたんだけど, あとはシングル・ログアウトを実装すれば少なくとも機能的には SAML 2.0 適合性の SP Lite を満たしそう. がんばれー. (などとエラそうにまとめてみる)

Wednesday Feb 15, 2006

サーバを追加することの代償

とくに他意はなく一般論として,

CTO のミッションとして 「サーバーを増やすだけで解決できるように努力する」 のは正しいけど, その一方で 「サーバを増やすことによって増加する管理費用をどう抑えるか」 は誰が考えるべきなんだろうか. CIO? CFO? はたまた, 運用コストを見落としたままサーバを増やそうと安易に考えてしまう CTO?

こういうことを考えてしまうのは, たぶん最近担当したり内部レビューしたりしているジョナサンのブログの和訳, とくに 「Linux on Intel の運用コストは Solaris 10 on x64 Sun Fire の 2 倍」だとか, 「Google や Yahoo! の経費の上から 2 番目にくるものは… 人件費についで電力使用料」 というエントリのせいなんだと思う.

そういえば会社のスライドからの孫引きだけど, 2002 年時点での 1 ラックあたりの使用電力 @ Google は業界平均の 5 倍前後らしい. いろんな意味で豪快.

Power in the Data Center

Wednesday Oct 12, 2005

Sun / Google 提携記者会見の筆記録が日本語訳されてる

jp.sun.com のホーム・ページに, 先日の Google との提携ネタが掲載された. あわせて記者会見の日本語版筆記録も公開されている.

企業の記者会見にしてはすごく面白い (と思う) ので, ウェブキャストを背後に流しながらぜひどうぞ. なんというか, 全編くどいくらいアメリカンな感じ (褒めてます).

About

tkudo

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today