なぜ、設計がセキュリティにおいて重要なのか？？セキュア・バイ・デザイン１章を読んで印象に残ったところの解釈と自身の体験とをまとめました

はじめに

最近セキュア・バイ・デザインを読み始めました。

読んでみて印象に残ったところを、

僕なりの解釈と僕自身の現場での体験とを交えながら１章ずつまとめてみようと思います。

今回は

第１章なぜ、設計がセキュリティにおいて重要なのか？？

についてまとめてみました。

ちなみに、、

先週、セキュア・バイ・デザイン 読書会 第2章「ちょっと休憩：『ハムレット』の悲劇」があり、

僕はまだ１章も読んでいない状態なので、追いついて次回の第3章には参加しようと、

急いでセキュア・バイ・デザインを読み始めたところです。。。。

ログイン機能作って安心ではダメ！！機密性、完全性、可用性そして追跡可能性は本当に大丈夫？？を常に心配事として捉え続ける！？

ログイン済みのユーザは自分がアップロードした画像の差し替えのみ可能とすべきなのに、

ある特殊な経路でアクセスすると全ユーザの画像が差し替えることが可能。

ただ、

お客さんから求められたログイン機能自体は、

ユーザID、パスワードを入力させてそれが正しければシステムを利用できるようにできている。

(ちょっと本とは違う例ですが、、)こんな感じの例から、

ログイン機能を作って安心するのではなく(セキュリティを機能として捉えるのではなく)、

本来の目的である本人のみ画像の差し替えが可能な状態に本当にできているのか？？(セキュリティを心配事として捉える)を意識すべき

というようなことが述べられていた箇所が個人的には印象的でした。

お客さんの要求通りログイン機能ができた。終わり！！ではなく、

常に更新権限を持っているユーザしかアップロード画像を更新できなく制御しているか？？を心配し続けられる方が、

いろんな攻撃されるシミュレーションをしたり、それに対策したりし続けられるので出来上がるシステムも全然変わってくるだろうなぁと思います。

自分自身を振り返ると、

以前、権限を詐称して権限のないユーザが本来見れないデータを参照できてしまっている。

という指摘を受けて、それ以降ログイン機能があるから問題ないという考えではなく、

設計の際は権限の詐称やなりすましをされた場合にも

参照可能ユーザ以外に参照させてしまわないか？？(機密性は大丈夫？？)

更新可能ユーザ以外に更新させてしまう可能性はないか？？(完全性は大丈夫？？)

を意識するように少し変わったなぁと思いました・・・

逆に、

セキュリティガチガチにしすぎてアップロード画像を取得するまでに何重ものロックを解除する必要があって使い勝手が悪いようなことはないか？？(可用性は大丈夫？？)

とか、

アップロード画像をいつ誰が更新したか追跡可能か？？(追跡可能性は大丈夫？？)

などの意識はまだ欠けているな。。。というのは反省です。

セキュリティ対策は専門家が必要(っぽく感じる)で設計は開発者が行うのが普通！！

セキュリティ対策と機能開発を分けてタスクを切る場合、

セキュリティ対策の方は専門家のタスクで機能開発における設計は開発者のタスクのように感じる。

しかも、セキュリティ対策は機能開発よりも優先度が落とされて最後の最後まで着手されない傾向にある。

だから開発者が自然に設計をすることがセキュリティ対策に繋がるような状態が良い。

というようなことが述べられていました。

僕も現場で脆弱性診断をリリース間際まで後回しにして脆弱性対策で大惨事になったりしたことがあるので、

専門家頼りにしてたり、後回しにしてたり。。。まさにその通りだなぁと。当時のことを思い返しました、、、辛かった

設計の質が上がればセキュリティも向上する！？

画面からユーザがユーザ名を入力してユーザ登録するのと、XSS(Cross[X] Site Scripting)攻撃を例に、

画面からから入力させたユーザ名をそのままstringで受け付けるから

<script>alert('ホゲほげ')<script>

が埋め込まれる。

ユーザドメインについて、ドメインエキスパートにヒアリングするとそもそもユーザ名として「<」などの記号は想定していない。

ユーザ名を受け付けるときに半角英数字のみ(「<」を受け付けない)という妥当性確認をすべきで、

さらに高凝集にするためにユーザ名を値オブジェクトとしてユーザドメインから切り離して・・・と設計を見直すべき

このドメインの理解を進め、設計を見直す過程においてセキュリティのことは一切意識していない。しかし結果的にXSSの対策に繋る。

というようなことが述べられていました。

ここを読むまでは、設計の質の向上がセキュリティに繋がるのはピンとこないなぁ・・・という感じでしたが、

なるほど、、、ほんとだ。。。ってなりました。ここについての感想はそれだけです、、

既知の脆弱性のについての理解と対策、設計の質向上、その両方のアプローチにより多層セキュリティによる防御

XMLパーサーの脆弱性とBillions Laughs攻撃とその対策を例に

XMLパーサーについての既知の脆弱性に対する推奨設定をするだけでなく、

XMLパーサーに読み込ませる値の妥当性確認の設計の両方から多層セキュリティによる防御がセキュリティ向上には大切。

というようなことが述べられていました。

一般的なXMLパーサーの脆弱性に対する推奨設定をする知識と持った上で正しく理解してセキュリティの設定を行うことと、

XMLパーサーにインプットする前に先程のユーザ名と同じように、stringで値を受け付けるのではなく、

ドメインエキスパートとドメインとして受け付けるべき値は何か？？を設計に正しく落とし込む。

この両方でセキュリティ対策を多層で行うことが非常に重要なのだと僕は解釈しました。

自分自身を振り返ると、

脆弱性周りの学習をしてXSS、CSRF、認可コード乗っ取り攻撃などなどの一般的なセキュリティヘッダの設定だったりの知識を得て次はこれさえ設定すれば

前回の脆弱性の時みたいに悲惨な目には合わないだろうと考えていたのですが、、、

設計の観点でも脆弱性対策できるところはきっちりとカバーし、

多層で防御するという考え方を持たないとな、、、ということを反省させられました。

まとめ

今回はセキュア・バイ・デザインの１章について僕が印象に残ったこれら４点について

僕なりの解釈と僕自身の現場での体験とを交えながらまとめてみました。

他の方の解釈なども聞きながらもっと理解を深めていけたらと思います。

結構本分厚いなぁ、、、、