CompTIA SY0-701: データセキュリティ、プライバシー、暗号技術 — 学習ガイド

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

こちらの一部です： CompTIA Security+ SY0-701 — 学習ガイド. 検証済みの解答で練習： CompTIA試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

データはほとんどの攻撃の最終的な標的であり、暗号技術は、転送中、保管中、および使用中のデータを保護するための主要な技術的メカニズムです。暗号プリミティブの特性、制限、そして正しい適用方法を理解することは、試験のためだけでなく、個々のコントロールが失敗した場合でもセキュアであり続けるシステムを設計するために不可欠です。

データ分類と取り扱い

データ分類は、取り扱い要件を決定する機密性ラベルを割り当てることです。政府のフレームワークでは、Unclassified (非機密)、Confidential (機密)、Secret (極秘)、Top Secret (最高機密) が使用されます。商用フレームワークでは、通常、Public (公開)、Internal (内部)、Confidential (機密)、Restricted (制限付き) (または同等のもの) が使用されます。分類は、利便性ではなく、データの機密性や規制上の義務に基づいて行われなければなりません。

データ損失防止 (DLP) システムは、エンドポイント、ネットワークの出口、クラウドストレージでコンテンツを検査することにより、取り扱いポリシーを強制します。DLP ルールは、クレジットカードのパターンに一致する16桁の文字列を含むメール添付ファイルをブロックしたり、ユーザーが「買収対象」というフレーズを含むファイルを個人のクラウドストレージサービスにアップロードしたときにアラートを出す、といったことを行います。DLP の有効性は、正確な分類に依存します。機密データにラベルが付けられていなければ、DLP はそれを保護できません。

データ主権は、データが物理的にどこに存在し、どの法域の法律が適用されるかに関する懸念です。GDPR は、EU域外に転送されるEUの個人データが、十分性認定、標準契約条項、または拘束的企業準則によって保護されることを要求します。グローバルに事業を展開する組織は、データフローをマッピングし、保管場所と処理場所が適用される規制に準拠していることを確認する必要があります。

転送中および保管中の暗号化

TLS 1.3 は、転送中のデータを暗号化するための現在の標準です。弱い暗号スイートを排除し、前方秘匿性 (一時的な Diffie-Hellman 鍵交換) を義務付け、ハンドシェイクを1往復に短縮します。TLS 1.0 と 1.1 は非推奨です。TLS 1.2 は依然として許容されますが、強力な暗号スイートで設定する必要があります。現在の標準を強制する Nginx の設定例です。

# Enforcing TLS 1.2+ in an Nginx server block
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;

保管中の暗号化は、ストレージメディア上のデータを保護します。フルディスク暗号化 (BitLocker, FileVault, LUKS) はボリューム全体を暗号化し、ファイルレベル暗号化 (EFS, VeraCrypt コンテナ) は個々のファイルを暗号化します。データベースレベルの暗号化 (SQL Server や Oracle の Transparent Data Encryption) は、データファイルとバックアップを暗号化します。重要なニュアンス：保管中の暗号化は物理的なメディアの盗難からは保護しますが、データを処理するためにすでに復号してしまった侵害されたアプリケーションからは保護しません。

暗号プリミティブ

共通鍵アルゴリズム (AES-128, AES-256, ChaCha20) は1つの共有鍵を使用し、高速であるため、大量のデータに適しています。公開鍵アルゴリズム (RSA, ECDSA, Ed25519, ECDH) は鍵ペアを使用し、鍵交換、デジタル署名、アイデンティティの紐付けを可能にしますが、計算コストが高くなります。ハイブリッドシステム (TLS など) は、公開鍵暗号を使用して共通のセッション鍵をネゴシエートし、その後、大量のトラフィックを共通鍵暗号で暗号化します。

ハッシュ化 (SHA-256, SHA-3) は、固定長のダイジェストを生成する一方向性関数です。ハッシュは暗号化ではありません。鍵が存在しないため、鍵を使って元に戻すことはできません。ソルト付きパスワードハッシュ (bcrypt, scrypt, Argon2, PBKDF2 を使用) は、ユーザーごとにランダムな値を追加して、レインボーテーブル攻撃を防ぎます。ハッシュは完全性の検証を提供します。HMAC はハッシュと秘密鍵を組み合わせることで、完全性と認証性の両方を提供します。

暗号モードは、アルゴリズム自体と同じくらい重要です。ECB モードの AES は各ブロックを独立して暗号化するため、同一の平文ブロックに対して同一の暗号文が生成されます。これはデータパターンを漏洩させる致命的な特性です。AES-GCM (Galois/Counter Mode) は、1回の処理で機密性と完全性の両方を提供し、現代のプロトコルの標準となっています。適切なパディングと HMAC を備えた CBC モードも許容されますが、正しく実装するのがより複雑です。

鍵の管理と保管

暗号技術の強度は、その鍵管理の強度に依存します。鍵は、強力なエントロピーで生成され、保護対象のデータとは別に保管され、スケジュールに基づいてローテーションされ、リタイア時には破棄されなければなりません。ハードウェアセキュリティモジュール (HSM) は、耐タンパー性の鍵保管と暗号処理の高速化を提供します。トラステッドプラットフォームモジュール (TPM) は、エンドポイント上のチップであり、BitLocker やメジャードブートで使用される鍵を保管します。キーエスクローは、法的な回復のために信頼できる第三者に鍵のコピーを預けるものであり、一方、キーリカバリーエージェントは、企業が必要な時に従業員のデータを復号することを可能にします。クラウドの KMS サービス (AWS KMS, Azure Key Vault, Google Cloud KMS) はエンベロープ暗号化を提供します。これは、データ暗号化キー (DEK) がデータを保護し、その DEK 自体は HSM に保持されているキー暗号化キー (KEK) によって暗号化される方式です。

公開鍵基盤 (PKI)

PKI は、認証局 (CA) によって発行された証明書を通じて、アイデンティティを公開鍵に紐付けます。下位 CA は、その証明書が事前に信頼されている必要があるルート CA にチェーンアップします。証明書のライフサイクルは、秘密鍵と共に生成される証明書署名要求 (CSR) から始まります。

openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr \
  -subj "/CN=www.example.com/O=Example Corp/C=US"

CA は要求者を検証し、CSR に署名して、X.509 証明書を発行します。失効情報は、証明書失効リスト (CRL) (失効したシリアル番号のリストで、定期的にダウンロードされる) または、証明書ごとの問い合わせにリアルタイムで応答する Online Certificate Status Protocol (OCSP) レスポンダーを通じて公開されます。OCSP ステープリングは、サーバーが TLS ハンドシェイク中に最近の署名付きステータスを提示できるようにすることで、クライアントから CA へのルックアップを回避します。証明書は有効期限が切れるため、更新が必要です。ACME (Let’s Encrypt, 内部 ACME サーバー) を介した自動化により、証明書の失効によるサービス停止を防ぎます。

コード署名と整合性検証

コード署名では、開発者のプライベートキーを使用してソフトウェアアーティファクトに署名します。受信者は開発者の証明書で署名を検証し、完全性とオリジン（出所）の両方を確認します。これにより、サプライチェーンにおける改ざんから保護されます。ファイル整合性監視ツール（Tripwire、AIDE）や、ハッシュ値の公開（ダウンロードファイルに添えられる sha256sum 値など）も同様に不正な変更を検出します。しかし、ハッシュだけではファイルがある値と一致することしか証明できず、誰がその値を作成したかを認証するものではありません。PKIに裏付けられたデジタル署名だけが、完全性と否認防止の両方を提供します。

保持、サニタイゼーション、安全な廃棄

保持ポリシーは、各データクラスをどのくらいの期間保持し、いつ削除しなければならないかを定義します。規制では、多くの場合、最小保持期間（例：財務記録を7年間）と最大保持期間（例：個人データは必要以上に長く保持しない）の両方が義務付けられています。バックアップも例外ではありません。データ主体が削除権を行使した場合、組織はバックアップからそのデータを削除するための正当なプロセスを持つか、技術的な制約と代替コントロールを文書化する必要があります。リーガルホールド（訴訟ホールド）は、通常の保持ポリシーに優先し、訴訟期間中はデータを凍結します。

メディアが寿命を迎えたとき、サニタイゼーション（無害化）はデータの機密性とメディアの処分方法に適合したものでなければなりません。NIST SP 800-88では、3つのレベルが定義されています：Clear（論理的な上書き。組織内での再利用に十分）、Purge（暗号消去、ブロック消去、または消磁。組織外での再利用に十分）、Destroy（シュレッダー、分解、焼却、粉砕）。暗号消去（暗号キーを破壊して暗号文を復元不能にする）は、自己暗号化ドライブを再利用する際に高速で効果的です。消磁（Degaussing）は磁気メディアを使用不能にしますが、SSDには効果がありません。物理破壊は、損傷したメディアや最高機密分類のデータに対して唯一確実な方法です。

実践シナリオ：キー管理の失敗による侵害

あるSaaS企業は、顧客データベースをAES-256で暗号化していましたが、暗号化キーをアプリケーションコードと同じリポジトリ内の平文の構成ファイルに保存していました。開発者が誤ってそのリポジトリをパブリックなGitHubアカウントにプッシュしたところ、自動化された認証情報スキャンボットが11分以内にキーを発見しました。攻撃者はそのキーを使い、公開アクセス可能なS3バケットに保存されていたデータベースのバックアップ（これは別の設定ミス）を復号しました。暗号化自体は技術的に正しく（AES-256はブルートフォース攻撃で破ることはできません）、しかしキー管理に致命的な欠陥がありました。適切なキー管理であれば、キーはソースコードや構成ファイル内ではなく、シークレットマネージャー（AWS Secrets Manager, HashiCorp Vault）に保存し、IAMロールによってアクセスを制御したはずです。

← クラウド、仮想化、コンテナセキュリティ · すべてのドメイン · 事業継続と災害復旧 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →