セキュリティルール作りのテクニック

セキュリティ担当者になれば、セキュリティポリシーを含めたルール作りに関わる機会が増えるはずだ。ルール作りのために欠かせない考え方について紹介しよう。

[松尾秀樹，セキュアシステムスタイル]

本コラムは2015年7月22日に公開した「セキュリティルール作りのテクニック」を再編集したものです。

　当然と言えば当然ですが、技術的な部分を抜きにルール作りは進みません。例えばパスワードの桁数や運用をどうするのかという視点でいえば、ルール策定時の標準的なコンピュータスペックに照らし合わせて、総当たりでチェックされたときにどのくらいの時間がかかるのか、どのくらいのペースで変更を行えば十分運用に耐え得るのかといった技術的な検証を踏まえたかたちで値を埋め込む必要があります。

　最初のルール作りには欠かせないアプローチで、開発ルールについても同じことがいえます。Webアプリの設計時には、「入力フォームやパラメータはセキュリティの観点からこうあるべき」という点を最初に十分検討したいところです。

　Webアプリのルール作りの際にはできるだけ説明しやすく作っていきましょう。具体的には「資料の中の何ページにある記述通りに作ってもらう、もしくは直してもらえば大丈夫」といった進め方ができるぐらいの資料があると現場も受け入れやすいはずです。

　そのためには、さまざまな開発言語に対応した表記の仕方が必要です。筆者もPHPやAndroidにおけるJavaコーディングといった一部の詳細資料までは用意できましたが、全ての言語に対応したルール作りは行うことができませんでした。自社で使われている言語を調べた上で、優先順位を付けていきながら進めていくべきです。

　どんなルールを作っていくべきかのひな型については、実際にはセキュリティベンダーなど外部パートナーの協力を得て作り上げてください。

パブリックな情報の使い方

　セキュリティのルール作りにおいて、IPAをはじめとしたさまざまな機関からルール作りの指針が公開されています。ただし自社のビジネスに照らし合わせてみると実務と乖離（かいり）した部分もあるため、運用面や利便性を含めた吟味が必要です。

　Webセキュリティについていえば、例えばWebアプリを作るときのセキュアプログラミングなどの手法や簡易チェックツールなどが公開されています。ただし現場に即したプログラミングが実装できるわけではありませんので、同様に吟味が必要になります。

ルールの運用について

　一度作り上げたルールは運用する中で更新の機会が必ず出てきます。そのとき多くの要望が寄せられることでしょう。例えば「パスワードを入れずにオートログインで運用したい」といった要望は必ず現場から上がるものです。

　現状のWebサービスが提供するユーザーインタフェースを追いかけながらルールを再考するべきです。全ての環境でオートログインを採用するのではなく、住所を新居に修正するとき、登録済みカード情報で決済するときなど、これまで以上に認証を詳細に行っていかなければいけないケースも出てきます。

運用面や利便性を含めた吟味が必要

　次回は、「ルールを現場に浸透させるためのテクニック」についてお話します。

著者紹介：松尾秀樹

1986年リクルート入社、コンピュータタイムシェアリング事業でスパコンの設置や運用を担当。1993年SI事業へ出向、大手クライアント技術支援。2002年システムセキュリティ担当、Webサービスの施策展開。2014年リクルート退職、セキュアシステムスタイル設立、代表取締役。「企業のセキュリティ担当者を支援するサービス」を提供中。