5.4セキュアOS・DB・アプリケーションセキュリティ

アプリケーションセキュリティの担当者・設計者にとって、「脆弱性を作り込まないこと」と「作り込んでしまった脆弱性を検出すること」は車の両輪です。開発ライフサイクルのどの段階で、どの技術・検査手法を適用すべきかを判断できることが、この節の核心です。OSレベルのアクセス制御からDB・アプリケーション層の実装対策・検査手法まで、防御層ごとに何が守れて何が守れないかを整理します。

5.4.1セキュアOS（MAC・RBAC・最小特権）

• 強制アクセス制御（MAC：Mandatory Access Control）＝ファイルやプロセスに付与されたセキュリティラベル（機密レベル等）に基づき、管理者があらかじめ定めたポリシーに従って一律にアクセスを制御する方式。ファイル所有者が自分の判断でアクセス権を変更できない点が、任意アクセス制御（DAC：所有者が裁量でアクセス権を設定できる方式）との決定的な違い。トラステッドOSの中核機能で、マルウェアや不正操作でも所有者権限だけではポリシーを覆せない。
• RBAC（Role-Based Access Control）＝利用者個人にではなく役割（ロール）に権限を割り当て、利用者をロールに所属させることでアクセス権を管理する方式。異動や退職時にロールの付け替えだけで済み、個々人へ権限を都度設定するより運用の一貫性と監査のしやすさが高まる。
• 最小特権の原則＝利用者・プロセスに業務上必要な最小限の権限のみを付与する設計原則。攻撃者がアカウントやプロセスを乗っ取っても、被害範囲をその権限内に限定できる。トラステッドOS＝MAC等のセキュリティ機能をOS自体に組み込み、独立した第三者機関による評価・認証（コモンクライテリア等）を経たOS。

5.4.2DBセキュリティとセキュリティバイデザイン・脅威モデリング

• DB暗号化＝データベース内のデータを暗号化して保存する対策。ストレージの盗難・不正アクセスによる生データの直接読み取りを防ぐが、正規の認証を経てDBに接続したセッションからは復号済みのデータが見えるため、DB暗号化だけでは内部不正・SQLインジェクション経由の情報漏えいは防げない——DBアクセス制御（利用者・アプリケーション単位の権限設定、必要最小限のテーブル・カラムのみ許可）と併用する必要がある。
• セキュリティバイデザイン＝開発の企画・設計段階からセキュリティ要件を組み込む考え方（後付けでなく最初から）。プライバシーバイデザイン＝同様に個人情報保護の要件を設計段階から組み込む考え方（収集は必要最小限に、既定値は最もプライバシーを守る設定に等）。脅威モデリング＝設計段階でシステムに対する脅威を体系的に洗い出し（データフロー図の分析等）、対策の優先順位を決める手法。上流で脅威を洗い出すほど手戻りコストが低い。

5.4.3セキュアプログラミングと脆弱性検出（SAST/DAST/IAST/SCA）

• SAST（Static Application Security Testing）＝ソースコードやバイナリを実行せずに静的解析し、脆弱なコードパターンを検出する手法。開発の早い段階（コミット時等）で適用でき修正コストが低いが、実行時の挙動に起因する脆弱性（設定不備・実行環境依存の問題）は見逃しやすい。
• DAST（Dynamic Application Security Testing）＝実際にアプリケーションを動作させながら外部から攻撃的な入力を送り、脆弱性を検出する手法。実行環境・設定起因の問題も検出できるが、ソースコードの該当箇所を特定しにくく、テスト対象の機能を網羅的に動かす必要があるため後工程での実施になりやすい。
• IAST（Interactive Application Security Testing）＝アプリケーション内部にエージェントを組み込み、実行しながら内部の処理経路も観測することでSASTとDASTの利点を組み合わせる手法（実行時の挙動を見つつコード上の該当箇所も特定しやすい）。SCA（Software Composition Analysis）＝アプリケーションが利用するオープンソースライブラリ・依存コンポーネントの既知脆弱性（CVE等）を棚卸しする手法で、自社で書いたコードではなく取り込んだ部品の脆弱性に対応する。

あるアプリケーション開発チームのセキュリティリードが、新しいECサイトの脆弱性対応計画を立てているとします。まず設計段階では、決済処理を含むデータフローを図示して脅威モデリングを実施し、「攻撃者が決済APIへ不正なパラメータを送る」「顧客の個人情報がログに平文で残る」といった脅威を洗い出し、実装前に対策の優先順位を決めます。実装フェーズに入ると、コミットのたびにCIパイプラインでSASTを走らせ、SQL文の組み立てでプレースホルダを使わず文字列連結している箇所（SQLインジェクションの典型的な作り込みパターン）を早期に検出し、修正コストが低いうちに直します。テスト段階では、ステージング環境で実際にアプリケーションを動かしながらDASTにより、実際にペイロードを送ってXSS（入力値がエスケープされずページに反映される）や認証まわりの実行時不備を外部視点で確認します。さらに、決済ライブラリとして利用しているオープンソースコンポーネントについてはSCAで既知のCVEを棚卸しし、脆弱バージョンを最新へ更新します。パスワード保存については、ハッシュ化するだけではレインボーテーブル攻撃に弱いため、利用者ごとに異なるソルトを付加してハッシュ値を一意にし、さらにハッシュ計算を意図的に繰り返すストレッチングで総当たり攻撃のコストを引き上げます。最後に、フロントエンドでは決済APIを異なるオリジンの外部スクリプトから呼び出させないようSame Origin Policyを前提とし、正規の連携先ドメインだけを許可リストで明示するCORS設定を行います。このように、上流の脅威モデリングから実装対策・複数の検査手法・パスワード保護技術まで、脆弱性のライフサイクル全体を通じて多層的に対応するのがアプリケーションセキュリティの実務です。

5.4.4この節のまとめ

• MACは管理者ポリシーで一律制御し所有者は変更不可（DACと対照的）、RBACはロール単位、最小特権は必要最小限の権限のみ
• DB暗号化は盗難読み取り対策でありDBアクセス制御と併用要。脅威モデリングは設計段階で脅威を洗い出し手戻りコストを下げる
• SASTは開発早期の静的解析、DASTは実行時の外部検査、IASTは両者の利点を統合、SCAはOSS依存の既知脆弱性を棚卸し。ソルトとストレッチングは目的が異なり併用が望ましい