LDAPサーバっておもろいね
相当個人的なので、こっちに書こう。
日本広しといえど、LDAPサーバベンダ（３つしかないと思っている。）の2社に所属してかつLDAPサーバ製品担当
をやっているのは、私ぐらいなので、このエントリはきっと価値が有るはず。
結論。
eDirectoryは割りといい。（でもベンダのエンジニアとか技術的に濃ゆい人はNoっていうとおもうけどね。）
なぜか。
LDAPサーバっていうけど、企業で運用していくためには、アクセス制御の設定とか、スキーマの定義とか、レプリケーションの設定とかが必要なんです。
つまり、製品・ソフトウェアとしてのLDAPサーバを選択する際には、「LDAPサーバそのもの」と「管理ツールとか」をまとめて考えなくてはいけないわけです。
Sun Java Directoryは、LDAPサーバとしては20数年くらいの歴史があるので、LDAPサーバ単体という意味では一番いいと思うね。ただ管理とか運用とかという意味では、結構たいへん。（スキルが必要なんですね。）
eDirectory は、LDAPサーバとしては10数年の歴史なので十分枯れている。で特筆すべきなのは管理機能。これはNetwareというネットワークOSを持っていた会社ならではだと思うんだけど、この管理ツールが結構使いやすい。（いい意味でブラックボックスなところもあってあんまり細かいこと意識しなくても設定とかできちゃうってのがすごい）
Active Directory は、私自身はあまりつかったことないので、わからないけど、Windowsクライアントの認証として使うことが重視（当たり前だけど）されているので、LDAPサーバというよりは、LDAPでも問い合わせできるよね。という感じだとおもう。Windowsクライアントの認証として使うことが重視するあまり、LDAPサーバとしての柔軟性にかけちゃっているイメージ。
でこれからが一番大事なんだけど。
今後、「LDAPサーバそのもの」ってことと「管理ツールとか」のどちらの要素が重要になっていくかっていうと、後者の「管理ツールとか」のほうなんだよね。
特に、アクセス制御の設定とか、セキュリテイ系の設定とかが大事になってくる。残念ながら、オープンソース系とか、Sun Java Directoryとかは、デフォルトのセキュリティ設定が甘いので、使うまでに行わなくちゃいけない設定多すぎだし。アクセス制御の設定は、難しい。（その点、eDirectory は初期設定はいけているし、アクセス制御の設定も簡単。Active Directoryは簡単だろうが、制限多いかな？多分。）
あと、情報システムの人たちは、どんどん忙しくなってくるので、「管理ツールとか」の使いやすさってホント大事になってくる。
で、相対的に、「LDAPサーバそのもの」としての機能の重要性が下がってくる。HWのコストがさがってるので、パフォーマンスとかは、速いCPUとたくさんのメモリと速いDISKでかいけつしちゃうんでね。
おまけ：LDAPサーバ毎に機能って結構ちがっていて面白いですわー。あれこんなこともできないの？とかへーこんなことできちゃうんだとか。
おしまい。
クラウドでセキュリティ向上
クラウドへの移行こそがセキュリティ確保の近道（中編） - クラウド・コンピューティング - TECHNOLOGY - CIO Online
から、
このことから、セキュリティ面で予想外のメリットが生まれているという。一般的にサーバについては、あらゆる使い方とアクセスする必要があるあらゆる人を考慮しなければならない。しかし、このセットアップでは、サーバはそれぞれ単機能であり、アクセス・プロファイルも1つしかない。
「各サーバは1つのアプリケーションのようなものだ。このため、操作しなければならない担当者には、必ず管理者レベルのアクセス権限が与えられている。原則として、別のセキュリティ・プロファイルは用意しない」（エミソン氏）
前にもどっかで読んだ気がするけど、アプリケーション（機能）＝1OSって考え方が新鮮。ソフトウェアベンダとしては、アプリケーション（機能）＝1OS ってなるように、単機能のアプライアンスとかを提供していくことになるだろうなー。
クラウド・コンピューティングの導入を検討している企業にとって、多くの場合、導入の最大のネックとなっているのはセキュリティだ。IT幹部もビジネス幹部も、機密データの保護や、アクセス制御、アイデンティティ管理、規制対応、マルチテナント方式の複雑さのほか、成熟した業界標準がないなかでベスト・プラクティスをどう見極めるかといったセキュリティ課題に頭を悩ませている。
しかし、クラウド・プロバイダーは早晩クラウド・サービスにセキュリティ機能を統合し始めるだろうと、米国のリサーチ会社フォレスター・リサーチのアナリスト、ジョナサン・ペン氏は見ている。そうなれば、こうしたセキュリティ課題のとらえ方も変わりそうだ。セキュリティ・ベンダーは、クラウド・プロバイダーがシステムやアプリケーション、データのセキュリティ確保に利用できる製品の開発を進めており、ペン氏は、クラウド・セキュリティ市場が拡大を続けて2015年には15億ドル規模に達すると予想している。同氏は、自身のブログにこう記している。
こっちもそうだよね。ただそれぞれのクラウドにセキュリティ機能が付加されるだけではだめで、それを束ねる（統合）するソリューションが必要になる、ID管理、アクセス管理、ログ管理（モニタリング）の頭に「統合」がついたやつ。もちろん統合の対象になるのは、オンプレミスもクラウドも、仮想化環境も全部ね。うーん。この市場は面白い。
仮想化セキュリティを考える上で考慮しなきゃいけないこと。
仮想化セキュリティについて押さえておくべき4つの基本ポイント - 仮想化 - TECHNOLOGY - CIO Online
から、
「仮想マシンはロケーションやIPアドレス、MACアドレスで定義するのが難しいうえ、外部のソフトウェアが1台の物理サーバ上にある仮想マシン間の通信を検出／フィルタリングするのも困難なことから、侵入保護などの基本的なセキュリティ・ツールは仮想マシンではうまく機能しない」と、同リポートを共同執筆したガートナーのバイスプレジデント兼フェロー、ニール・マクドナルド氏は指摘する。
これ認識しとかないとダメ。仮想化環境なので、IPアドレス、MACアドレスは変化する前提で考えていかないと行けない。
ってことは、これまで、レイヤー2とかレイヤー3とかを中心に考えていたセキュリティ対策は再考の必要あり。
SIEMソリューション（ログ管理ソリョーション）が見逃しちゃう点。
Generic accounts are your SIEM blind spot
前からちょっと引っかかっていた内容がはっきりしました。
特権ユーザとか特権IDとかのログっていうのは、ログ管理製品で集めても、あつかいずらいんですよね。
rootとかAdministratorとかにログに出てきても、実際にそのアカウントを使っているのが誰なのかってことがわからないんですよね。
知りたいのは、「誰」ってことなのにね。その場合には、特権ID管理製品とSIEMとの連携が必要ってこと。できれば同じベンダで連携実績あるほうがいいよね。
同じパスワードを使っちゃう心理。
Are Your Employees' Gaming Passwords Putting Your Enterprise at Risk? | Okta
を見て思ったけど、結構多いかも。これの弊害を防ぐために、OpenIDだったり、SAMLだったりで認証連携して、パスワードを使う場所を減らす。減らした場所ではセキュリティを高めるってのが大事にですな。
Novell のソーシャルメディアのスライドシェア
Social media class 3 http://www.slideshare.net/NOVL/social-media-class-3
Social media class 2 http://www.slideshare.net/NOVL/social-media-class-2
Social media class 2 v2 http://www.slideshare.net/NOVL/social-media-class-2-v2
Social media class 1 http://www.slideshare.net/NOVL/social-media-class-1-v2
キャリアが支配するケータイに終わりを告げたのはAppleとGoogleの共闘チームだ | TechCrunch Japan
(2)App Storeという単一チャネルにユーザを閉じこめたため、ユーザはこれまでに購入したアプリケーションを無駄にしたくないから、ほかのメーカーの機種に移行する動機を失った。
確かに、確かに、スイッチングコストは上がりまくりだ！！！ まーいーけど。。
