(Translate to English)
Thursday Oct 19, 2006
地方公共団体における情報セキュリティポリシーに関するガイドライン (平成 18 年 9 月版)
という文書の 「3.5.4 ＩＤ及びパスワード等の管理」 に書かれている遵守事項の例文が,
なかなかすごいことになっている:
(3) パスワードの取扱い
職員等は、自己の管理するパスワードに関し、次の事項を遵守しなければならない。
- パスワードを秘密にし、パスワードの照会等には一切応じてはならない。
- パスワードを記載したメモを作成してはならない。
- パスワードは十分な長さとし、文字列は想像しにくいものにしなければならない。
- パスワードが流出したおそれがある場合には、情報セキュリティ管理者に速やかに報告し、パスワードを速やかに変更しなければならない。
- パスワードは定期的に、又はアクセス回数に基づいて変更し、古いパスワードを再利用してはならない。
- 複数の情報システムを扱う職員等は、同一のパスワードをシステム間で用いてはならない。
- 仮のパスワードは、最初のログイン時点で変更しなければならない。
- パソコン等の端末のパスワードの記憶機能を利用してはならない。
- 職員等間でパスワードを共有してはならない。
地方公共団体における情報セキュリティポリシーに関するガイドライン (平成 18 年 9 月版)
これらひとつひとつの項目はまっとうな内容に思えるけど
(6 を除く. 理由は後述),
すべてを同時に達成することって実際にできるんかな!?
とくに上で強調 (太字) した5 項目を遵守するのは相当難易度高いと思うなあ.
ヘタすれば, どれも守れなくて結局セキュリティは低下,
しかもユーザの利便性はどん底,
パスワード忘れの問い合わせへの対応は増える一方になるような気がする.
すこし前 ('02) の調査だけど,
IT システムを常用している一般的なユーザが管理しているパスワードの数は 21 個だという話がある.
また利用者がパスワードを完全にコントロールできる
(自分の覚えやすい文字列を使い, 自分が忘れる前に変更する)
ならまだしも, パスワード・ポリシー, たとえばよくあるところだと
- パスワードを変更するタイミング
- パスワードに使用することのできる文字種・長さ
- パスワード履歴に基づく使用禁止ポリシー
などは, そのパスワードを格納するシステムごとに異なっているはずだ.
そのような環境下でこんな運用↓をユーザに強制させることができるとすれば,
そこは相当記憶力がいい人の集まりに違いない.
- パスワードは十分な長さとし, 文字列は想像しにくいものにして下さい.
同一のパスワードをシステム間で用いてはならないことになっていますから,
システム毎に異なるパスワードを設定していただきます.
なおそのパスワードを記載したメモを作成してはならないですし,
またパソコン等の端末のパスワードの記憶機能を利用してはならないことは言うまでもありません.
最後に,
パスワードは定期的に, 又はアクセス回数に基づいて変更を強制されます. また古いパスワードを再利用してはならないように設定されています. ご注意下さい.
おそらく, この例文を作成した方は 「認証」 と 「認可」
をごっちゃにしていたのではないだろうか (ああ, またココにも
「認証基盤」 というダメ言葉の弊害が!).
その誤解を示しているのが, 項目 6 の
「複数の情報システムを扱う職員等は、同一のパスワードをシステム間で用いてはならない」
という文言.
たぶんパスワードがひとつ盗まれても他のシステムのパスワードは違うから,
被害は広がらないよーっていうことを意図してるんだろうけど,
本当に必要なのはそうではなくて,
システム / アプリケーションごとに適切な認証レベルを設定することのはずだ.
たとえばこんな感じ:
- 社員ポータルと Web
メールとインスタント・メッセージングは共通の認証レベルで十分であると定義し,
パスワードを一元化 (さらにはシングル・サインオン) する.
- 一方, 人事システムへのアクセスは人事担当者のみに制限する必要があるので認証レベルを上げ,
パスワードだけでなくディジタル証明書の提示も要求する.
- さらに, 経営情報管理システムはより高い認証レベルが必要であると定義し,
パスワードだけでなくディジタル証明書も必要,
特定の階 (ボード・ルームのあるフロア) の端末からしかアクセスを許可しない.
このへんの考え方は
「政府機関の情報セキュリティ対策のための統一基準」
を解説する
「政府機関統一基準の説明資料（2006年8月2日）」
の #81 - #95 になかなかよくまとめられている.
あとはもちろん,
弊社のアイデンティティ管理ソリューションもお忘れなく ;)
(Translate to English)
Monday Oct 16, 2006
8 月に開催し, 多くの方のご参加をいただいた
「アイデンティティ管理ソリューション活用セミナー」 を,
来月の 9 日にもう一度行なうことになった.
実際の適用例として,
今回は岩片さんがパスワード管理について説明する予定.
一方, ぼくの担当するセッションは前回と同じく, IdM の基本と将来の動向について.
つまりまとめると
- 『アイデンティティ管理・監査の基礎と応用』 では
「認証基盤」 から 「内部統制」 まで, IdM にまつわるいろいろを概観し,
- 『異機種混在環境でのパスワード管理と同期手法』 では典型的な IdM 適用パターンのひとつを紹介して,
- 『アイデンティティ管理に関する標準化動向』 では SAML 2.0 や SPML 2.0 を見据える
という感じの 2 時間半,
どうぞよろしくお願いします.
(Translate to English)
Tuesday Nov 29, 2005
アイデンティティ管理システムが解決する問題は多岐にわたるが,
そのうちどの分野からとりかかるべきだろうか?
以下の文章は
METAspectrum 的には Challenger
な某競合他社の資料からの引用なんだけど,
主張している内容にはおおむね同意できる.
Clearly, a simple deployment and short time-to-ROI means that
password management should be activated early in an identity
management project. Early deployment gives the organization
early ROI, and gives the project visibility and credibility
that it can leverage to carry out the business process discovery
and design required to activate an user provisioning system.
Deploying password management before access management
いま動いているアイデンティティ情報同期のシステムやプロセスを捨てて,
いきなり新しい仕組み
(アイデンティティ・プロビジョニング: アイデンティティ情報のライフサイクル管理)
に置き換えるのは, 導入効果は大きいが一方費用的・時間的なリスクも大きい.
そうではなく,
既存の環境を維持したまま新しい仕組み
(パスワード管理: パスワード同期およびパスワード・ポリシーの統一)
を追加し,
投資対効果を早期に確保した上でアイデンティティ・プロビジョニングへと堅実に歩を進めるアプローチのほうが理にかなっている.
「既存の内製のデータ同期システムにもパスワード管理機能は入っている」
という場合もあるかもしれない.
しかしそれははたして本当に 「パスワード管理機能」 と呼べる代物なのかどうか,
一度確認してみたほうがよい.
利用者からパスワードという属性を Web
インタフェース経由で受け取り各リソースへ同期させる,
という仕組みはすでに多くの組織内で実現されている.
しかしパスワード・ポリシー, たとえば過去に設定したことのあるパスワードの再利用を拒否したり,
「数字を 1 文字, 特殊文字を 2 文字いれること」 のような規則を設定したり,
180 日後に失効させたりといったところまで, 現状のシステムには実装されているだろうか?
そしてそれらの設定は, 要件の変化に応じて
Web インタフェースなどから容易に変更できるだろうか?
Sun のアイデンティティ管理製品ラインではどうなっているかというと,
パスワード管理機能は
Sun Java System Identity Manager (SJS IDM)
の一部としてワークフロー・エンジンやデータ同期と同列に,
バーチャル・アイデンティティやエージェントレス・アダプタを活用するかたちで実装されている.
これにより
「まず既存のリソースや ID データ同期の仕組みはそのままにパスワード管理を強化し,
その後様子を見ながら徐々にライフサイクル管理を IDM に移行する」
かたちで基盤整備を進めていくことができる.
加えてパスワード・ポリシー機能もアイデンティティ・プロビジョニング製品の単なるオマケ的なものではなく,
- 長さ: パスワードの最小・最大文字数の制限
- 文字の種類: 各種文字 (英数字, 特殊文字) の最小および最大個数, 繰り返し・連続の制限など
- 辞書: 辞書の単語と照合
- パスワード履歴: 過去 n 回以内に用いたことのあるパスワードや文字の使用禁止
- 使用禁止単語: 特定の単語を禁止
- 使用禁止属性: 別の属性値 (氏名, ID など) と同じ値をパスワードに含めることの禁止
のように, ポリシーの要件を実装する上できめ細かい設定ができるようになっている.
また SJS IDM という単一のバイナリには, ライセンス体系が 3 種類設定されている:
- Web インタフェースを伴うワークフローやセルフサービスなどを含めた全機能を使うための full use ライセンス
- パスワード管理機能のみを使うための password management ライセンス
- データ同期機能のみを使うための data sync only ライセンス
後者の 2 種類の利用制限ライセンスは full use ライセンスよりも安価に設定されているから,
まず password management ライセンスによって SJS IDM 導入コストを抑えつつパスワード管理を強化し,
のちに full use ライセンスへアップグレードすることで,
導入した SJS IDM 運用環境をさらに有効活用することが可能となる.
さきに書いた通りこれらのライセンスは使用許諾される範囲の違いだけであって,
提供されるバイナリは全く同一であるため,
password management ライセンスで導入した IDM を full use
にアップグレードする際に (某競合他社のアプローチとは違って)
他の製品やモジュールを追加インストールする必要はない.
ということで, 「パスワード同期からはじめる IdM」 を実践するには
Sun Java System Identity Manager
が技術的・価格的にもイケてるなーということを考えてたら,
ちょうどイギリスでも同じようなことをスライドにしてる人がいた.
こちらもあわせてどうぞ.
|
|
|
|
