Toshio.Kuniya@Sun.COM Kuniya's Review

こりゃびっくり。

東京大学を中心とした研究チーム、10ギガビットネットワークを利用したインターネット速度記録を完結

話は大分横道にそれますが。。。。
CERNは LHCの実験でいわば「データベース・グリッド」のアプローチで地球上に分散する、おそらく人類史上一番デカイ計算機を持とうとしています。

世界中の研究拠点（たとえば日本は東大のICHEPP）に実験データを分散配置し、世界中の研究者は（おそらく）数Petaにもおよぶ自分のデータを各グリッドから読み出し並列計算をします。似たような研究を行っている他人よりも1秒でも速く解析を行いたい！的な要件はそこに実際に存在します。

なので、当然データベースの技術もRDBMSではまったくスケールしないので、多分自作のDBを使いますし、つい最近も、ネットワークの技術で新聞記事がでていたような。

こんなふうに、必要な技術ってこれまでは物理屋がゴリゴリ自前で作ってきたわけだけど（その技術を手土産にベンダーの研究所に就職したり。。。）、さすがに、このレベルは無理かな。脱帽。というか、LCはこれを実用する時代と重なるなぁと、ある意味ジェラシー！？。

にしても、Solarisでやってもらえればもっとうれしかったが。。。。Open Solarisは調達規定は満たしていると思うんだけど？

ISACA の Control Journal 最新号に「ERP Security and Segrigation of Duties Audit: A Framework for Building an Automated Solution」というのがありましたので読んでみました。Part 2では、paperの内容に即して、現在のトレンドおよび課題をまとめてみます。

ま、読まなくても想像で多分そうなんだろうなということが、記述されています（笑）。

気が利かない部分はあると思いますので、つっこみコメント歓迎です。

現在のトレンドおよび課題

監査費用全体コストの中で、ERPセキュリティが占める割合が増加傾向にある。ビジネス面での課題解決を優先させてきたため、（当然ながら）SIにおいても職務分掌について十分な配慮がなされてこなかったという経緯がある。というわけで、いまさらになって職務分掌のためのERPセキュリティは大きな問題となっている。

IT監査にかかわるトレンドはこんな感じ。（国谷：実際の数値などは文献を引いてください）

• ERPセキュリティや職務分掌の評価に多大なコストがかかっている
• ERPセキュリティについて監査や実装を出来る人が少ないため、トレーニングへの需要が高い
• ERPシステムのユーザに対して職務分掌をモニタリングする製品のオファーが増えている

でも実態として、こんなケース(SAP R/3の場合)をどう扱うのか。。。。

中堅企業はエイヤっと数えて、100種類のトランザクションコードを利用している。そのトランザクションは通常2つ程度の権限（SAPロール）が必要になる。その企業では 200人の利用者がいたとする。その200人には20通りの業務や責任（国谷：大抵参照ユーザや、複合ロールの数に相当するかな）があったとする。この場合、検討すべきERPセキュリティの組み合わせは、
100 x 2 x 200 x 20 = 800000 通り
これは、最もシンプルに考えた場合なので、トランザクションコードの中身によってはさらに複雑になるかもしれない。

実は、監査を支援する、といわれるERPツール群も、実は全く機能不足である場合が多い。なぜなら、それらのツールの多くは、ERPセキュリティについて設定を支援するためのもので、効果的、効率的な職務分掌の監査を支援するものではない。しかも、それらのツールは、決まって、ただ駄目出しをしてくるので、余計な仕事だけが増えるという、ユーザからの不満が続出している。

これまでのアプローチとしては手でやってきたわけだが。。。。

今日、ほとんどのERPユーザでは手作業によるセキュリティ監査を実施している。 ERPに付属するセキュリティ報告ツールは、セキュリティの設定に関する精度のみが論点になりがち。

決まった期間内に統制の対象となっているトランザクションコードを調査するためには、ツールのスケーラビリティ性能に由来する制限を理解する必要がある。

と、以上です。

あるトランザクションコードを調査するとき、それを実行できるあるユーザが持つ権限のリストがチェックされて、そのトランザクションコードにとって不適切な兼任となりうる権限が含まれていないかを確認する。
こういうチェックの方法だと、確かに上に挙げたような組み合わせの数だけ調査が必要で、しかもひとつのバッチジョブでこなそうとすると、トランザクション毎、ユーザ毎にループがまわるので、恐ろしいくらい時間がかかる。これでは、大企業にはまったく適用できないかもしれない。しかも、この調査ではおそらく、トランザクション、ユーザ単位の権限の問題点が、ズラーっと画面に表示されるだけで、監査が期待する報告を出力とは異なるという事らしいので、「ふーん、アメリカでもそういう状態なんだ」となんとなく安心というか、見切ったというか。

ただ、20通りの参照、複合ロールっていう規模は、日本でもよくあるサイズかな。 1パターンのチェックで10秒かかるとしても、800000通りということは、93日かかりますな。 半分の時間だとしても、50日弱、1秒ならば1週間。うーーん、会計監査って何日で済ませないといけないんだっけ（爆）

ISACA の Control Journal 最新号に「ERP Security and Segrigation of Duties Audit: A Framework for Building an Automated Solution」というのがありましたので読んでみました。（下道さんありがとうございます。）

こんな記事やあんな記事を書いた手前、この手の話題には努めて興味を持つようにしています。

実際読んでみた第一の感想は「世の中、実態はそんなもんか」に尽きます。アメリカは SOX 対応がすでに3週目に突入しています。それでも未だにERPのセキュリティについては、まぁ、手をこまねいているという事です。

論文で提案されている結論は、まず、ERPの仕組みをよく理解することが大前提となっています。さらに、監査要件を満たす情報を取り出す仕組みは ERP に組み込むのではなく、外部システムとして用意することを推奨しています。

また、一番気になったのは、ERPで職務分掌を確立するためには、それを実現する技術的背景と実装としてのテーブルなどを特定すること、という点です。
うーん、そこまでシステムの裏側を理解できているなら、なにも手組みで「SOD検証システム（造語）」なんか作らなくても、IdM上で実装しちゃえばいいのに。と思ったりもします。

ちょっと長くなりそうなので、このpaperで議論されていることはまた、次回まとめてみます。

今回の出張で、Deloitte や ITガバナンスのチームと会話したことをメモっていたので、 それをブログに転載してみることにします。
ようわからんところもあるかもしれませんが、ご容赦。

結論：

• なぜSOXへ対応する必要があるのか、企業統制に対する意識が世界的に高まってきているから（あまり理由になっていない。。。）
• ITへのインパクトは大きい
• 効率的なコンプライアンスを継続できないといけない
• 外部監査とのつきあい方が変わった（これはUS独特の状況かな）

現場の意識

• 文書作成だけが仕事じゃない
• 解決すべき統制欠陥がたくさん発生している
• 現在の統制は効率的とは言えない
• 統制活動は間に合わせの手法でしのいでいる（結果痛い目にあっている）

サイロ、分散型のマネージメントを変えて、かつガバナンスのゴールも高めに設定する。じゃないと、内部統制の報告で不備ややり直しがあまりにも多い

非SEC企業がSOXを適用し始めている（これは驚き）

SOX対応 1年目のアメリカの空気

• 監査が非常に多くを求めるので、組織やデータの処理やシステムなど多くを学ぶはめになった
• 情報の質（これは別途紹介する機会を持つべきかな）が悪い
• 精度、信頼性、透明性、タイムリーさを維持することの難しさを実感しているし、これは永遠の課題である

ITアプリケーションが標準化、統合されていない

テクノロジーの利用は最小限にとどめておくのが効率的で効果的であると思っていたが結果として、ITとビジネスの協調性を失うことになった （全体のプロセスの15%しかシステム化されていない）

SOX対応 2年目のアメリカの空気

• 経営層と監査人の会話が進んだ
• だれが責任者かが意識されるようになった
• 教育、トレーニングの範囲が全組織に及び、何が問題なのかを理解・意識させた
• コストはかかっているが、SOX対応の長所が認識され始めた（この具体性を知りたいところだが）

SOX対応 現在：

統制の合理化が今まさに起こっている
コンプライアントという結果は既存にうわのせる形では実現しない、コンプライアンスが組み込まれる必要がある

ほとんどがITにインパクトはないと思っていたという考えを撤回し、効率的効果的に支えるためにはテクノロジーが重要だという認識になった

• 61% の企業がSOX対応2年経過しても財務情報に関して十分なクォリティを確保できていないと感じている
• 80% のシステムが統合されずにある

しかも、責任者は激務のようだ。

• CFO の在職期間は3年以下
• CIO の在職期間は2年以下

とまぁ、上っ面を並べると、当たり前のようなことばかりですが、 普段「事例、事例」と騒がしい日本が、先行事例から素直に学べるのかどうか （いろんな意味で）お手並み拝見っていう気がしています。

さらにITサイドがもう少し意識すべきことを学べる paper を 2本紹介します。 一つは deloitte.com から、「IQ matters」 というもの。 もう一つは、ISACA の Control Journal から「ERP Security and Segrigation of Duties Audit: A Framework for Building an Automated Solution」です。

前者はちょっとキツイので時間がかかっていますが、後者はあっさりと簡単に読めました。 実は後者は結論もあっけないので、それをベースに次回はUSにおけるERPセキュリティの実態について書きたいと思います。

来週月曜日に初人間ドックを控えていることをすっかり忘れて、メタボなUS出張をしてしまった私です。今週中頃からぼちぼちと仕事は復帰していますが、健康診断はあきらめました（爆）。

実に下らなくて申し訳ないのですが、今回の出張で通じなかった英語をばらしてしまいます。

• ア・ボトルド・ウォーター（a bottled water）
• バニラ・ラテ（vanilla latte）
• リライ・オン（rely on）

やはり「L」と「R」の発音がどうしても苦手なのと、「T」の音便（であってるか？）が難しい。。。。あと、単語だけのやりとりになると通じない傾向があるかな。文章になると前後を読み取ってくれるのか意外とよく通じるという印象があります。

3/28 に、jp.sun.com のトップページから Feature Story を提供させて頂くことになりました。

小さな会社であるサンならではの醍醐味といいましょうか、私が所属するSAPチーム＋Identity Managementチーム＋SI営業チームなど、要するに日頃の仕事で「仲の良い」野郎どもで、縦割り組織を破って、横串しに仕事を（勝手に）立ち上げました。

一年以上前から on demand で会話する機会があったのですが、最近はがっちりと一緒に案件の作戦を練ったり、検証すべき事の話し合いをしています。

ハードウェアに固執していると思考が止まってしまいやすいので、ソフトウェアを売る人たちと仕事をすると結構刺激的です。

今週はビジネス・ガバナンス・プロジェクトの仕事としてUSに来ていることもあり、新鮮なネタをこの記事とともに、商談のなかでカバーさせて頂ければと思います。

数ヶ月もblogを書かないと、リバウンドが激しい。3連チャン。
＃実は「下書き」的には4連チャンなのですが、さすがにそれは止めときます。

インテル社に、その歴史がよく分かる展示コーナーがあるのは有名です。一般的に「面白い」といわれているのですが、何が面白いのかはあまり知りませんでした。

で、実際に行ってみたところ、企業イメージをどのように購買者に対して植え付けていくのか、インテル社のその巧みさがよく分かる資料館だと感じました。

全体としてはよくできた資料館なのですが、一部非常に面白くない点があり、かなり引っかかっています。

インテル社の成功を理由づけるキーとなったイベントがいくつか指摘されていて、それとなく展示室全体にちりばめられています。相当、日本企業が憎かったんでしょうね。。。

• 不公平な商売による価格の下落に対して戦ったこと
• ○○のフラッシュの発明よりも効果的な技術を見つけたこと
• ○○や○○を破りトップの。。。。。（うぅぅ、書けない！）

実際に、メモリからプロセッサーへ戦略をシフトさせていったことは成功要因だったと思います（Blue Oceanに乗り移り、その一方で半導体としての固有値・固有ベクトルは維持した...ちょっとした流行り言葉で書くとこうなる）が、不公平なtradeというのはアメリカらしい勝手な言い訳だよなぁと、個人的には不満たらたらです。

アメリカ企業の悪いクセは、企業間競争で勝てないのは環境要因、つまりそこに必ず不正があるせいだと決めるつけることです。それを政治的に取り除くことが国益を守るという思考回路になっていて、インテルの場合は80年代の日米構造協議だったと思います。TRONの失敗も有名ですが、NECのPC98のCPUがV30からi286に切り替わったのもこの時期であることは忘れもしません。

ま、でもそのおかげで、私はサンで働くことができているのかもしれませんが。

サンも展示室作ったらいいのに。。。。
TCP/IPの標準実装とか、NFSとか、SMPとか、CMTとか、言えることはいっぱいあるけどなぁ。。。。

TOEICで700点以上になっても相変わらず片言英語しか話せない私が、同僚と仕事以外の話ができていたのは自分でも驚きの今日この頃です。
（自分の中ではTOEIC700点って、結構ぺらぺらだろうと想像していました）

アメリカの大学へ留学した日本人が、アメリカに残ってビジネスコンサルの仕事をしているケースをあまり見かけないけどどうして？と聞かれたのですが、どう答えればよかったのでしょう（笑）。
要するに、中国人やインド人はニューヨークのど真ん中で「御社の業務改革とは。。。」と語っているのに、サンのビジネスの範囲ではなかなかそういうキレる日本人に会わないんだそうです。

彼が言うには、IT業界での英語のスキルというのは、結構低くても問題ないそうです。実際、ほとんどのUSのIT企業は英語を母国語としない従業員を抱えています。と同時に、その人達は製品開発の中心人物であるので、経営層のメッセージをきちんと理解させることが重要だから、そんなに難しい言い回しはできないんだそうです。
でも、ビジネスコンサルと製品開発は使う英語の質が違うよなぁ、とつっこんでみたり。。。。

それでも、ジョナサンの英語はやっぱり難しいよね。と、ジョナサンのブログの日本語化を行った経験を話したところ、「ジョナサンのブログはずいぶんと簡単な英語だけど・・・・」と言われました。

ぐはっ、結構低くてもいいという英語のレベルは、少なくとも私が想像する「低さ」とは比べものにならないくらい高いようです。。。。