学習目標
「何を守るための仕組みか」を一言で説明してから選択肢を比べる。認証、認可、暗号化、改ざん検知、監査は相互に代替できない。セキュリティはSAの公式重点分野だが、個別技術の出題比率が固定されているわけではない。
認証と認可
認証は、主張する主体と認証情報の対応を確かめること。認可は、その主体に対象データや操作を許すか決めること。ログイン済みでも全レコードへのアクセスを認めてよいわけではない。各要求について主体・操作・対象をサーバ側で照合する。
多要素認証は知識、所持、生体など異なる種類の要素を組み合わせる。パスワードと暗証番号は両方とも知識要素なので、それだけでは多要素にならない。認証方式はフィッシング耐性なども別に評価する。NIST SP 800-63B-4
暗号・ハッシュ・署名の比較
| 仕組み | 主目的 | 鍵・秘密 | 注意点 |
|---|---|---|---|
| 共通鍵暗号 | データの秘匿 | 共有する秘密鍵 | 認証付き暗号など適切な方式・運用が必要 |
| 公開鍵暗号 | 公開鍵で暗号化し対応する秘密鍵で復号など | 公開鍵と秘密鍵の組 | 対応する公開鍵が誰のものか確認する |
| 暗号学的ハッシュ | データの要約・改変検出の部品 | 通常は鍵なし | 値を単独で添付するだけでは攻撃者が両方交換できる |
| MAC | 共有秘密に基づく完全性・真正性確認 | 共有秘密鍵 | 検証できる側も生成できる |
| デジタル署名 | 改変検知と署名鍵による生成の検証 | 署名用秘密鍵と検証用公開鍵 | 本文を秘密にする機能ではない |
署名は「秘密鍵で本文を暗号化すること」と一般化しない。署名アルゴリズムは方式固有で、RSA以外にもある。検証成功の意味は、対応する鍵でその内容の署名が作られたこと。鍵の所有者との結び付き、鍵の保護、失効状況なども重要である。NIST FIPS 186-5
脅威と対策の対応
| 脅威 | 本質 | 主な設計対策 |
|---|---|---|
| SQLインジェクション | データがSQL構文として扱われる | パラメータ化クエリ、必要箇所の許可リスト、最小権限 |
| XSS | 信頼しない内容がブラウザでコードとして動く | 出力先文脈に応じたエンコード、安全なDOM操作、必要なHTMLの無害化 |
| CSRF | 利用者の認証状態を悪用して意図しない要求を送る | CSRFトークン、Origin等の確認、適切なSameSite設定を組み合わせる |
| オブジェクト単位の認可欠落 | IDを変更すると他人の対象を操作できる | サーバ側で対象ごとのアクセス権を確認 |
OWASP SQLインジェクション対策、XSS対策、CSRF対策
判断例
「HTTPSにしたので注文SQLに入力文字列を連結してよい」は誤り。TLSは通信経路を保護するが、受け取った文字列の解釈を安全にはしない。値をSQL構造から分けるパラメータ化を使う。テーブル名等、値用パラメータでは扱えない動的構造は固定化や許可リストで制限する。
間違えやすい点と確認
- パスワード保存には単なる高速ハッシュでなく、ソルトを用いる適切なパスワードハッシュ方式を使う。ソルトは秘密鍵ではない。
- フロント画面でボタンを隠すだけでは認可にならない。APIへの直接要求を検証する。
- デジタル署名を付ければ本文を読めなくなるか？ → ならない。秘匿には別の暗号化が必要。
- 監査ログがあれば不正を防止できるか？ → ログは検知・追跡に役立つが、防止策の代替ではない。
出典と適用上の注意
全て独自説明・独自図。古い暗号方式や旧認証指針を問う過去問は、当時の正答根拠と現行運用の推奨を分ける。古い設問に登場したことを現在の採用理由にしない。