横断領域 暗号・クラウド・法務
Aug 4, 202518 min
この章の位置付け
重点5テーマだけでは、科目Bの出題範囲を完全にはカバーできない。暗号・クラウド・法務は、どの大問にも部品として登場する。この章は 必須の横断知識 として扱う。
| 領域 | 優先 | 重要用語 | 詳しくは |
|---|---|---|---|
| ネットワーク | A | TCP/IP、NAT/NAPT、FW、ACL、プロキシ、TLS、DNS、DNSSEC、DoH、IPsec、IKEv2、SSL-VPN、ZTNA | sc_4 |
| ネットワーク | B | VLAN、802.1X、ARP・DHCPスプーフィング、IDS/IPS、NDR、WAF、リバースプロキシ | sc_4 |
| メール | A | SPF、DKIM、DMARC、アライメント | sc_4 |
| メール | B | STARTTLS、SMTPS、S/MIME、MTA-STS、DANE、BEC、メールヘッダーの分析 | sc_4 |
| 暗号 | A | AES、RSA、ECC、ECDSA、ECDH、SHA-2、HMAC、共通鍵・公開鍵暗号、鍵交換、電子署名、証明書 | この章 |
| 暗号 | B | AEAD、AES-GCM、前方秘匿性、鍵のローテーション、OCSP、CRL、証明書チェーン、TLS 1.3 | この章、sc_3 |
| クラウド | A | IAM、最小権限、責任共有モデル、設定不備 | この章 |
| クラウド | B | CSPM、CASB、CWPP、CNAPP、Secretsの管理 | この章 |
| 法務・ガバナンス | B | 個人情報保護法、漏えいの報告、委託先の監督、システム監査 | この章 |
1. 暗号：目的から選ぶ
科目Bでは、暗号アルゴリズムの内部構造ではなく、目的に対して適切な技術を選べるか が問われる。
| 目的 | 技術 | 注意点 |
|---|---|---|
| 機密性（大量のデータ） | 共通鍵暗号：AES | 鍵の共有方法が課題 |
| 機密性＋完全性 | AEAD：AES-GCM、ChaCha20-Poly1305 | 同じ鍵でnonce（IV）を 再利用してはならない |
| 鍵の共有 | 鍵交換：ECDHE（一時的な鍵） | 相手の認証は別途必要（証明書、署名） |
| 完全性（改ざんの検知） | ハッシュ関数：SHA-256 | 単独では改ざん者がハッシュ値も作り直せる |
| 完全性＋送信者の確認（共通鍵） | HMAC | 鍵を共有する者同士では否認防止にならない |
| 完全性＋真正性＋否認防止 | デジタル署名：RSA、ECDSA、EdDSA | 公開鍵の真正性は証明書で保証する |
| パスワードの保存 | Argon2id、bcrypt、scrypt、PBKDF2 | ソルト、計算コスト（sc_3） |
1.1 よく問われる区別
- ハッシュ値とHMACの違い：ハッシュ値は誰でも計算できる。改ざんした者がハッシュ値も計算し直せば検知できない。HMACは鍵がなければ計算できない。
- HMACと署名の違い：HMACは送信者と受信者が同じ鍵を持つため、「受信者が作った」可能性を排除できない（否認防止にならない）。署名は秘密鍵を持つ者しか作れない。
- 暗号化と署名の鍵：公開鍵暗号で暗号化するときは 受信者の公開鍵、署名するときは 送信者の秘密鍵 を使う。
- 前方秘匿性：一時的な鍵交換（ECDHE）を使うと、長期の秘密鍵が漏えいしても過去の通信を復号できない（sc_4）。
- ECC：RSAより短い鍵長で同等の安全性が得られる。
1.2 危殆化と移行
| 危殆化しているもの | 移行先 |
|---|---|
| MD5、SHA-1（署名用途） | SHA-256以上 |
| DES、3DES、RC4 | AES |
| RSA 1024ビット | RSA 2048ビット以上、ECC |
| TLS 1.0 / 1.1、SSL | TLS 1.2 / 1.3 |
耐量子計算機暗号（PQC）：大規模な量子コンピューターが実用化されると、RSAや楕円曲線暗号が解読される可能性がある。NISTはML-KEM（鍵カプセル化）、ML-DSA・SLH-DSA（署名）を標準化した。今の暗号通信を記録しておき、将来解読する攻撃（Harvest Now, Decrypt Later）への備えとして、長期間秘密にすべきデータから移行を検討する。どのシステムがどの暗号を使っているかを把握し、アルゴリズムを切り替えやすくしておくこと（クリプトアジリティ）が重要である。
2. クラウドのセキュリティ
2.1 責任共有モデル
| 責任 | IaaS | PaaS | SaaS |
|---|---|---|---|
| データ、アカウントの管理 | 利用者 | 利用者 | 利用者 |
| アプリケーション | 利用者 | 利用者 | 事業者 |
| OS、ミドルウェア | 利用者 | 事業者 | 事業者 |
| 物理、ハイパーバイザー | 事業者 | 事業者 | 事業者 |
どのサービスモデルでも、データとアカウント（IAM）の設定は利用者の責任 である。クラウドでの事故の多くは、事業者側の問題ではなく、利用者の設定不備によるものである。
2.2 IAM
| 要素 | ポイント |
|---|---|
| 最小権限 | ワイルドカード（全操作・全リソース）での許可を避ける |
| ルートアカウント | 日常的に使わない。MFAを設定し、利用を監視する |
| 長期間有効なアクセスキー | ソースコードやCIへの直書きが漏えいの原因になる。ロールによる一時的な認証情報に置き換える |
| サービス間の連携 | ワークロードにロールを割り当てる。外部のCIとはOIDC連携で一時的な認証情報を使う |
| 権限昇格 | IAMのポリシーを変更できる権限、ロールを引き受ける権限を持つと、自分に管理者権限を付与できる |
2.3 典型的な設定不備
- ストレージ（オブジェクトストレージ）の 公開設定 による情報漏えい
- 管理用のポート（SSH、RDP）をインターネット全体に公開
- 監査ログ（API呼出しの記録）を無効にしている、保存期間が短い
- メタデータサービスへのアクセスが、SSRFで悪用できる設定（sc_2）
- 使っていないリソースが残っている（DNSのCNAMEと組み合わさったサブドメインテイクオーバー、sc_4）
2.4 クラウド向けのセキュリティ製品
| 製品 | 役割 |
|---|---|
| CSPM | クラウドの設定を継続的に検査し、設定不備を検出する |
| CWPP | 仮想マシン・コンテナなどのワークロードを保護する |
| CNAPP | CSPMとCWPPなどを統合する |
| CASB | SaaSの利用状況の可視化（シャドーIT）、データの持出しの制御 |
| Secretsの管理 | 認証情報・APIキーを一元的に保管し、ローテーションする |
3. ゼロトラスト
「社内ネットワークの内側なら信頼する」という境界型防御をやめ、すべてのアクセスを都度検証する 考え方。
| 原則 | 内容 |
|---|---|
| 明示的な検証 | 利用者、端末の状態、場所、リスクを、アクセスのたびに評価する |
| 最小権限 | 必要なリソースに、必要な期間だけアクセスを許可する（JIT） |
| 侵害を前提とする | 侵入された場合の被害範囲を小さくする（マイクロセグメンテーション）、監視と記録 |
構成要素：IDaaS（認証の一元化と条件付きアクセス）、端末の管理（MDM、EDR）、ZTNA、SWG・CASB（SASEとして統合）、ログの集約と分析。
境界型の限界を問う設問：VPNで接続した後は社内のすべてのサーバにアクセスできる構成で、1台が侵害されると横展開を止められない。ゼロトラストの考え方では、アプリケーション単位でアクセスを制御し、端末の状態を継続的に確認する。
4. 生成AIのセキュリティ（補強）
業務システムへの生成AIの組込みは、Webアプリケーションの問題として出題される可能性がある。
| リスク | 内容 | 対策 |
|---|---|---|
| プロンプトインジェクション | 利用者の入力や、AIが読み込む外部の文書に含まれる指示によって、意図しない動作をさせる | AIの出力を信頼せず、権限を持つ操作の前に検証・承認を挟む |
| 過剰な権限 | AIに連携したツールが、利用者が持つ以上の権限で動作する | AIが呼び出すAPIでも、利用者本人の権限で認可を検証 する（sc_2 の認可と同じ構造） |
| 情報漏えい | 入力した機密情報が学習に使われる、他の利用者の応答に出る | 利用規約の確認、入力してよい情報のルール、DLP |
| 出力の扱い | AIの出力をそのままHTMLやSQLに埋め込む | 通常の入力と同様にエスケープ・プレースホルダー |
5. 法務・ガバナンス
5.1 個人情報保護法の漏えい等の報告
次の場合、個人情報保護委員会への報告と本人への通知 が義務になる。
- 要配慮個人情報の漏えい等
- 財産的な被害が生じるおそれがある個人データ（クレジットカード番号など）の漏えい等
- 不正の目的によるおそれがある漏えい等（不正アクセス、ランサムウェアなど）
- 1,000人を超える個人データの漏えい等
報告の期限：
| 報告 | 期限 |
|---|---|
| 速報 | 事態を知った後、速やかに（おおむね3〜5日以内） |
| 確報 | 30日以内（不正の目的によるおそれがある場合は 60日以内） |
- 漏えいが 確定していなくても「おそれ」がある段階で報告の対象になる。ランサムウェアで個人データを含むサーバが暗号化され、情報が持ち出された可能性を否定できない場合が典型。
- 委託先で漏えいが起きた場合も、委託元に報告の義務がある。委託元は委託先を 監督する義務 を負う。
5.2 その他の法令
| 法令 | 科目Bでの論点 |
|---|---|
| 不正アクセス禁止法 | 他人の識別符号の無断使用、アクセス制御の回避。識別符号を不正に取得・保管する行為、フィッシングサイトの開設も処罰の対象。アクセス管理者には防御措置の努力義務 |
| 不正指令電磁的記録に関する罪 | いわゆるウイルス作成罪。正当な理由なく作成・提供・供用すること |
| サイバーセキュリティ基本法 | 国・地方公共団体・重要インフラ事業者などの責務 |
| 能動的サイバー防御に関する法律（2025年成立） | 重要な基幹インフラの事業者によるインシデントの報告、政府による通信情報の利用やアクセス・無害化の措置。段階的に施行される |
| 電気通信事業法 | 通信の秘密。通信の内容を監視する場合の利用者の同意 |
| 刑事訴訟法 | 証拠としての電磁的記録の扱い |
5.3 システム監査
- 監査人は、監査の対象から 独立 していなければならない。
- 監査の結論は、監査証拠（ログ、記録、インタビュー）に基づく。
- 例：「アクセス権の棚卸しを定期的に行っている」ことを確かめるには、棚卸しの実施記録と、その結果に基づいて権限が削除された記録を確認する。
~Yu Tokunaga