2005年12月20日

セキュアプログラミング(Java編)修了 〜 テクニカルエンジニア(情報セキュリティ)試験対策

日曜日の研究会のツケで、1日遅れの仕上げになった。最終的には、「セキュアプログラミング講座」のまとめ、ということになったのだが、以下のような感じだと思う。テクニカルエンジニア(情報セキュリティ)試験とはいえ、ネットワークとプログラミングの両方のスキルを問うというのは、現場のエンジニアにとっても、試験範囲が未経験の分野に及ぶことになるので、負荷が高い試験になるかもしれない。あるいは、問題を選択式にして、選ぶという構えとも想定できなくもない。情報セキュリティアドミニストレータの延長というわけにはいかないようだ。

さて、少々手間取ったが、総括してしまうと意外とシンプルである。
1.危険なクラスたち
 クラスの悪用に対する警戒がテーマ。システムリソースに対するアクセスや特権が得られるクラスを「特権的処理」に限定し、「一般的処理」には限定的なクラスにとどめる。また、セキュリティポリシーは、きめ細かくパーミッションを見直して、必要最小限の権限を設定する。

2.カプセル化のすすめ
 オブジェクトの基本的なコンセプトは、フィールド・メソッドを保護するという考えに基づくもの。従って、クラスの外部からのアクセスは、必要最小限にとどめる。方法としては、リードオンリーインターフェースを用いると良い。また、クラス・インターフェースの名称は、ソースコードの監査がしやすいものを命名する。

3.シリアル化と情報漏洩
 シリアル化は、本来、ファイルの保存や送受信のための手段で、セキュリティ対策はされていない。情報の漏洩を防ぐためには、出力するフィールドの抑制と暗号化対策が基本。また、RMI、EJB実装の際は、注意が必要(ここは試験の対象外と思うが)。

4.クラス継承となりすまし
 クラス継承として、ポリモーフィズム機能は便利ではあるが、サブクラスとして「なりすまし」のリスクがある。継承が危険なものはfinalクラスによる防御を施す。

5.Javaのアサーション
 アサーション機能は、プログラムの正しさを検証する手段であり、ロジックそのものではない。検証の方法としては「事前条件」「事後条件」「クラス不変条件」のいずれかを意識して行う。

6.synchronizedとレースコンディション
 複数スレッドで共有する資源のアクセスでは、レースコンディション問題が発生する可能性があるが、発見・対策は困難な場合が多い。基本は、synchronizedメソッドにより同期させることは可能だが、処理性能が低下する。多用・乱用は避け、最小限の部分をsynchronized文でガードする方法もある。

ということで、Perlに掛かる。シンプルというより、かなり適当な言語という印象がある。基本は短めにやって、「適当さ」に伴うリスク対策を押さえる、ということになるか。
posted by tamaso at 00:37| Comment(0) | TrackBack(0) | 学習実績 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
この記事へのトラックバックURL
http://blog.seesaa.jp/tb/10844575

この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。