あとからセキュリティ強化策を実装するのは困難
「モバイルファースト」「クラウドファースト」という目標は、なかなか企業で実現できないからこそ “スローガン”となっている側面があるように、「セキュリティファースト」も十分に実現できておらず、設計時点でセキュリティの考慮がなされていない傾向があります。
そこでまず、具体例を紹介しましょう。本連載では繰り返し、セキュリティの特性（機密性、完全性、可用性）を維持するためには認証が重要であることを解説しています。その重要性があまり考慮されていない例として、ローカル認証において、すべてのPCのローカル管理者のIDとパスワードが同一になっていることを悪用されていることを取り上げています。
この改善策としてAdministratorというOSのデフォルト値の管理者用のアカウント名を変更することや、パスワードをPCごとに個別にユニークにすることが挙げられます。また、これを機に従来パスワードの長さが６文字だったものを８文字にして、少しでも推測されにくいものにしようと改善が試みられるケースもあります。
技術的には大して難しい問題ではなく、過去の連載でも紹介したグループポリシーやLAPSというツールの適用で、比較的簡単にこうした目標は達成できるはずです。ところが、現実にはそうは簡単にはいかない場合があるのです。
- 独自開発したシステムでパスワード６文字固定の入力フィールドにしているシステムがあるので、そのシステムを改修するまではパスワードを８文字以上にすることなどできない。また、こうしたパスワード文字数に制限のあるシステムが他にもあるか分からないので、調査しないとパスワードの強化策に着手できない。
- スクリプトやバッチで Administrator というアカウントとパスワードを埋め込んでいるので、どんなシステムにどんな影響があるのか分からない。
といった場合です。こうした事情から、大規模な環境ではそう簡単にセキュリティ強化策は実装できないことがお分かりいただけると思います。しかし、まさにこれはセキュリティファーストを目標としてこなかった実装が招いた結果と言えます。
- アプリケーションの開発時点で、パスワードの長さを固定ではなく可変に対応しておく
- そもそもスクリプトやバッチに本当に管理者権限が必要かを検討する
- やむを得ず管理者権限が必要だとして、OSのデフォルト値をそのまま使わずAdministrator以外の名前になっても対応できるようにしておく
- スクリプトやバッチの中に認証処理を必要としない方式を検討する
- それでも事情によりこうした運用が避けられないときは、それを監視したり、定期的に監査し、何かあったときにはすぐに現在の運用が提示できたり、説明できるようにする
結果論と思われるかもしれませんが、どれも実装前に検討可能なことばかりではないでしょうか。
