C4: 最初からセキュリティに対処する (Address Security from the Start)
説明
新しいアプリケーションを設計する際、安全なアーキテクチャを作成することで、脆弱性がアプリケーションの一部になる前に防止できます。これによりコストのかかる修復や否認の問題を防ぎます。
安全なアーキテクチャにつながる設計原則は以下のとおりです。
簡潔にしておく (KISS): アプリケーションが理解しやすいほど、そのコンポーネントとそれらのインタラクションについて判断しやすくなります。これによりアプリケーションのセキュリティ動作について判断できます。
正しいことを簡単にできるようにする: ユーザーがドキュメントを読んだり、「正しいやり方」に時間を費やすことを期待してはいけません。デフォルトでアプリケーションが安全な振る舞いをすべきです。安全でないようにするには、ユーザーが明示的なアクションを実行する必要があります。
隠蔽に依存しない: セキュリティがアプリケーションやそのソースコードの不透明性だけであるならば、そのアプリケーションはまったく安全ではありません。
公開されているコンポーネント (「攻撃対象領域」) を特定して最小化する: 攻撃者はそこにないものをすることはできません。
多層防御を設計する: コンポーネントが侵害された場合に何が起こるのか、および攻撃の潜在的な影響範囲について考えます。
ライブラリやフレームワークなどのサードパーティコンポーネントの使用
すべての要件を手動で実装することは可能かもしれませんが、確立されて適切に保守されているサードパーティコンポーネントをベースにアーキテクチャを構築することを強くお勧めします。これには複数の利点があります。
車輪の再実装はしない で、他の人の (セキュリティの) 失敗から学びましょう。多くの場合、既存のライブラリやフレームワークはセキュリティ監査を受けており、セキュリティ問題が特定され、最終的に改善されています。他の人のセキュリティ作業から恩恵を受けましょう。
安全なデフォルト: 防御的で安全なデフォルトを提供するフレームワークが増えています。リスクのある動作を有効にするには、開発者による手動操作が必要です。
その上で最新の状態に保つ。メンテナンスされたフレームワークを使用することで恩恵を得られる一方で、そのフレームワークの新しいリリースを追跡して、セキュリティ上の注意点を確認するというメンテナンスの負担があることはご存じのとおりです。
フレームワークと戦わない。フレームワークを使用することが、すべてのステップでフレームワークと戦っているように感じるのであれば、その具体的なフレームワークはあなたの開発スタイルやアーキテクチャに適していないのかもしれません (あるいはその逆かもしれません)。
脅威
アプリケーションが隠蔽によるセキュリティ (security-by-obscurity) でのみ保護されている場合、アプリケーションをリバースエンジニアする攻撃者は難読化が解除されるや否や完全なパーミッションを有します。さらに、攻撃者はネットワークトラフィックを監視できます。難読化はコードレベルで実行されるかもしれませんが、ネットワークレベルのオペレーションは簡単に解析できます。
複雑な認可スキームを持つウェブアプリケーションがデプロイされます。新しいソフトウェア開発者はコンポーネントの一つを拡張する仕事を任されます。その複雑さゆえに、認可スキームを設定ミスし、攻撃者は IDOR を悪用できます。
複雑な認可スキームを持つウェブアプリケーションがデプロイされます。新しいソフトウェア開発者はそのシステムに新しいプラグインを追加します。システムは正しいことをするのが難しく、すべてのセキュリティ設定を手作業でプラグインに追加しなければならず、デフォルトではセキュリティ対策は講じられません。新しい開発者は何も設定していないため、新しいプラグインはシステムに IDOR を導きます。
あるウェブアプリケーションは多くのコンポーネントがあり、すべてパブリックインターネットに公開されています。その結果、攻撃対象領域は膨大になります。たとえば、データベース管理ツール (
phpmyadmin
など) がデプロイされています。mysqladmin
にゼロデイが見つかった後、データベース全体が抽出されました。通常の使用では、phpmyadmin
を使用する人はいません。
実装
「複雑さはセキュリティの敵である」という格言は、この実装ガイダンスの随所に見られます。
明確かつ明瞭に設計する
アーキテクチャはシンプルであることに重点を置くべきです。設計したソフトウェアは意図したユーザーの要件が許す範囲内でのみ複雑にすべきです。シンプルであることに重点を置くと、作成されるソフトウェアにいくつもの利点をもたらします。
シンプルなシステムについて判断が容易になります。これにより変更に伴う潜在的なセキュリティの影響を判断できます。
よりシンプルな設計により、長期的なメンテナンスが容易になります。
設計は透明性に重点を置くべきです。つまり、セキュリティは隠蔽によるセキュリティ (security-by-obscurity) に依存してはいけません。
正しいことを簡単にできるようにする
よく耳にする言葉に「Security By Design」と「Security By Default」があります。前者はソフトウェアシステムが安全に使用できるべきであることを意味し、後者はソフトウェアシステムの初期設定が安全であることを意味します。
つまり、システムに安全でない設定を導入するには、システム管理者が明示的に選択する必要があることを意味します。対照的に、最も抵抗の少ない道は常に安全なシステムをもたらすはずです。
エンドユーザーのインタラクションに焦点を当てる場合、この側面はユーザーインタフェースとフローを設計する上で重要です。開発者のインタラクションに焦点を当てる場合、フレームワーク、API、ネットワーク API などの開発者向けの機能は、デフォルト値で使用するときに安全な操作のみが行われるように設計すべきです。設定ファイルを設計するときにもこの点を考慮してください。
何をするために何が信頼されているかを明確にし、それらの関係が確実に実行されるように確保する
何をするために何が信頼されているかを明確にし、それらの関係が確実に実行されるように確保します。たとえば、信頼境界は影響範囲を定義し、ファイアウォールやゲートウェイなどのコントロールによって実行されます。
各ステップでの慎重なバリデーションによって、許可されるものを減らします。STRIDE などの脅威モデリングのニーモニックや、要素ごとの STRIDE などの方法論でより深く掘り下げます。
公開されているコンポーネント (「攻撃対象領域」) を特定して最小化する
攻撃者がアクセスできるすべての領域を特定し、それらをレビューして、最小化するように努めます。攻撃者はそこにないものを攻撃することはできません。
さらに、最小限の操作セットのみを公開することで、長期的なメンテナンスが容易になります。
よく知られたアーキテクチャパターンを使用する
専門家はセキュアアーキテクチャパターンと呼ばれる理解しやすい形式でベストプラクティスに関する知恵を共有しています。アーキテクチャパターンは再利用可能であり、複数のアプリケーションに適用できます。
ソリューションがパターンとみなされるには、以下の特性を備えていなければいけません。
第一に、セキュアアーキテクチャパターンはセキュリティ問題を解決しなければなりません。
第二に、セキュアアーキテクチャパターンは特定のベンダーやテクノロジに縛られてはいけません。
第三に、セキュアアーキテクチャパターンは脅威を軽減する方法を示さなければなりません。
第四に、セキュアアーキテクチャパターン は再利用を容易にするために、脅威とコントロールについて標準化された用語を使用しなければなりません。
アーキテクチャパターンは標準的なソリューションを使用して問題を解決する方法であり、カスタムソリューションを作成するものではありません。セキュアアーキテクチャパターンは既知のセキュリティ脅威に対してレビューされ強化された標準的なソリューションです。
実装:
解決すべき問題を特定します。
利用可能なセキュアアーキテクチャパターンのカタログを検討します。
設計にセキュアアーキテクチャパターンを選択します。
セキュアアーキテクチャパターンを実装します。
防止される脆弱性
ビジネスロジックの欠陥: これらのパターンは複雑で見過ごされがちなビジネスロジックの脆弱性を回避するようにアプリケーションを構成する際に役立ちます。
OWASP Top 10 2021-A04 (安全でない設計): セキュアアーキテクチャパターンは、OWASP が強調する主要な懸念事項である、安全でない設計に関連するリスクの軽減を直接のターゲットとしています。
参考情報
ツール
Last updated