Thursday Oct 19, 2006

記憶力自慢の組織向けのパスワード管理ポリシー

地方公共団体における情報セキュリティポリシーに関するガイドライン (平成 18 年 9 月版) という文書の 「3.5.4 ID及びパスワード等の管理」 に書かれている遵守事項の例文が, なかなかすごいことになっている:

(3) パスワードの取扱い
職員等は、自己の管理するパスワードに関し、次の事項を遵守しなければならない。

  1. パスワードを秘密にし、パスワードの照会等には一切応じてはならない。
  2. パスワードを記載したメモを作成してはならない。
  3. パスワードは十分な長さとし、文字列は想像しにくいものにしなければならない。
  4. パスワードが流出したおそれがある場合には、情報セキュリティ管理者に速やかに報告し、パスワードを速やかに変更しなければならない。
  5. パスワードは定期的に、又はアクセス回数に基づいて変更し、古いパスワードを再利用してはならない。
  6. 複数の情報システムを扱う職員等は、同一のパスワードをシステム間で用いてはならない。
  7. 仮のパスワードは、最初のログイン時点で変更しなければならない。
  8. パソコン等の端末のパスワードの記憶機能を利用してはならない。
  9. 職員等間でパスワードを共有してはならない。

地方公共団体における情報セキュリティポリシーに関するガイドライン (平成 18 年 9 月版)

これらひとつひとつの項目はまっとうな内容に思えるけど (6 を除く. 理由は後述), すべてを同時に達成することって実際にできるんかな!? とくに上で強調 (太字) した5 項目を遵守するのは相当難易度高いと思うなあ. ヘタすれば, どれも守れなくて結局セキュリティは低下, しかもユーザの利便性はどん底, パスワード忘れの問い合わせへの対応は増える一方になるような気がする.

すこし前 ('02) の調査だけど, IT システムを常用している一般的なユーザが管理しているパスワードの数は 21 個だという話がある. また利用者がパスワードを完全にコントロールできる (自分の覚えやすい文字列を使い, 自分が忘れる前に変更する) ならまだしも, パスワード・ポリシー, たとえばよくあるところだと

  • パスワードを変更するタイミング
  • パスワードに使用することのできる文字種・長さ
  • パスワード履歴に基づく使用禁止ポリシー

などは, そのパスワードを格納するシステムごとに異なっているはずだ. そのような環境下でこんな運用↓をユーザに強制させることができるとすれば, そこは相当記憶力がいい人の集まりに違いない.

  • パスワードは十分な長さとし, 文字列は想像しにくいものにして下さい. 同一のパスワードをシステム間で用いてはならないことになっていますから, システム毎に異なるパスワードを設定していただきます. なおそのパスワードを記載したメモを作成してはならないですし, またパソコン等の端末のパスワードの記憶機能を利用してはならないことは言うまでもありません. 最後に, パスワードは定期的に, 又はアクセス回数に基づいて変更を強制されます. また古いパスワードを再利用してはならないように設定されています. ご注意下さい.

おそらく, この例文を作成した方は 「認証」 と 「認可」 をごっちゃにしていたのではないだろうか (ああ, またココにも 「認証基盤」 というダメ言葉の弊害が!). その誤解を示しているのが, 項目 6 の 「複数の情報システムを扱う職員等は、同一のパスワードをシステム間で用いてはならない」 という文言. たぶんパスワードがひとつ盗まれても他のシステムのパスワードは違うから, 被害は広がらないよーっていうことを意図してるんだろうけど, 本当に必要なのはそうではなくて, システム / アプリケーションごとに適切な認証レベルを設定することのはずだ. たとえばこんな感じ:

  • 社員ポータルと Web メールとインスタント・メッセージングは共通の認証レベルで十分であると定義し, パスワードを一元化 (さらにはシングル・サインオン) する.
  • 一方, 人事システムへのアクセスは人事担当者のみに制限する必要があるので認証レベルを上げ, パスワードだけでなくディジタル証明書の提示も要求する.
  • さらに, 経営情報管理システムはより高い認証レベルが必要であると定義し, パスワードだけでなくディジタル証明書も必要, 特定の階 (ボード・ルームのあるフロア) の端末からしかアクセスを許可しない.

このへんの考え方は 「政府機関の情報セキュリティ対策のための統一基準」 を解説する 「政府機関統一基準の説明資料(2006年8月2日)」 の #81 - #95 になかなかよくまとめられている. あとはもちろん, 弊社のアイデンティティ管理ソリューションもお忘れなく ;)

Tuesday Oct 03, 2006

CEC 2006: トップダウン・アイデンティティとボトムアップ・セキュリティ

CEC 2006 の初日.

Day 1 Opening

今朝のゼネラル・セッションの中で, グレッグ・パパドポラスTop-down Identity and Bottom-up Security という表現を使ってた. アイデンティティとセキュリティはしばしば一緒くたにされがち (「認証基盤」 はそのような誤解の典型. /etc/passwd のメンテナンスや PKI の延長で IdM を考えてると絶対失敗する) なので, このように課題へのアプローチの起点を明確にして, それぞれの違いをはっきりさせるのは良いことだと思う.

Thursday Jun 29, 2006

「アリスとボブ」 ネタのラップ

C'est la vie! 経由. MC Plus+ (MC プラスプラス) による, アリスとボブの間での安全なメッセージ交換についてのラップ. 超おもろい!

Friday Mar 31, 2006

UltraSPARC T1 の SSL アクセラレーション + Solaris 10 のカーネル内 SSL プロクシ

Web サーバ絡みでもうひとつ. UltraSPARC T1 プロセッサに搭載されている RSA / DSA アクセラレーション機能の利用方法の解説が, 新着 BluePrint として公開された.

(This BluePrint) provides a brief overview of SSL technology, as well as an introduction to the Solaris Cryptographic Framework. Configuration details are included for common security applications, such as Apache, the Sun Java(TM) System Web Server, and secure Java(TM) technology applications, enabling these programs to utilize NCP and KSSL technology. A performance study of secure Web applications is also included.
Using the Cryptographic Accelerator of the UltraSPARC T1 Processor, Sun BluePrints(TM) OnLine - March 2006

以前 T2000 発表の際に出てきた諸情報をいろいろ眺めてたときにも思ったんだけど, 個人的にはやはり Greyhound こと KSSL (Kernel SSL proxy) との組み合わせに強く惹かれる. KSSL は従来外部に置かれたリバース・プロクシやスイッチが行なっていたような SSL の終端処理をカーネル内でやってしまうというもので, おおよその動作はこんな感じ ↓ (なにか間違ってたらツッコミ願います > Sun の中の人, とくに笹沼さん野崎さん希望 :)

  • Web サーバ (に限らないけど) はポート 8080 (非 SSL) をリッスンし, 一方 KSSL はポート 443 (SSL) に反応するよう設定する.
  • Web クライアント (に限らないけど) が SSL でポート 443 に接続すると KSSL は SSL ハンドシェイクやその後の復号化処理を行ない, 非 SSL なポート 8080 で待っている背後の Web サーバに平文でリクエストを転送する. Web サーバは平文でコンテンツを KSSL に返却し, それを KSSL が暗号化して Web クライアントに送る.
  • しかも一連の SSL 処理はカーネル内で, Web サーバと同じコンテクストで実行されてて, Web サーバからは Web クライアントが直接 non-SSL でポート 8080 に接続してきてるようにみえる.
  • さらに芸が細かいことに, Web サーバに設定した非 SSL なポートに外部から接続できなくなったり (KSSL からのみ接続可能), SSL ハンドシェイクのなかで KSSL が Web クライアントの提示してきた SSL 暗号スイートに対応してない場合には従来通り Web サーバに SSL 処理させるようフォールバックすることができたりする.

KSSL

この KSSL と, UltraSPARC T1 によるハードウェア RSA アクセラレーションを合わせた効果は絶大なようだ. 本 BluePrint 曰く, Sun Java System Web Server の SSL 性能がほぼ倍に向上したという.

SPECweb99_SSL

ついでに SPECweb2005 の世界記録もたたき出してる (2006 年 1 月 26 日時点).

SPECweb2005

もしかしてコレ, T2000 の 60 日間無償貸出のベンチマークネタのひとつに最適な気がしてきた. ぼくは社員なので応募するのは無理だけど, 今度の某イベントのデモ用に T2000 が都合ついたらちょっと試してみようかなあ.

Wednesday Dec 07, 2005

CoolThreads サーバ上で Java ES

NC05Q4
本日未明の CoolThreads サーバのローンチ直後から, 驚くほど多種多様な技術情報が外部に公開されている. ここではその中でも Java Enterprise System (Java ES) に関連してそうなネタをいくつか書き留めてみる.

Friday Jul 08, 2005

Sad news

鈴木優一さん亡くなったそうだ. 直接の面識は無いのだが, 過去に iPlanet / Sun ONE で LDAP や PKI, Identrus 関連のソフトウェア製品を担当し, 現在は IdM ソリューションにかかわっている自分にとって, 鈴木さんの著作はいつも大変参考になるものばかりだった. 感謝の気持ちをあらわすとともに, ご冥福をお祈りしたいと思います.

Thursday Oct 28, 2004

Network Security Forum 2004

Network Security Forum 2004 にて, Identity Manager の展示の説明員仕事を手伝う. といっても, 会場に着いたのは閉場一時間前だったので, たいして役にはたたなかったけど.
会場を一巡してみた感じでは, 紹介されている製品やサービスはファイアウォールや侵入検知などに関するものが多く, ID 管理製品を展示しているのは我々だけだった... まあ考えてみると展示会の表題からして 「ネットワーク・セキュリティ」 なので, そういう傾向になるのは当然なのかもしれない.
本展示会は明日まで開催しているので, ご興味のある方はどうぞ (要登録だけど, まだ間に合うみたい).
About

tkudo

Search

Archives
« July 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
31
  
       
Today