CCSP 2026 試験対策フラッシュカード:6ドメイン総復習

2026年8月改訂のCCSP試験概要を、日本語の要点説明と英語の重要用語で復習できる、インストールして使える学習カードです。

Σχετικά με αυτήν τη δέσμη

2026年8月改訂のCCSP試験概要を、日本語の要点説明と英語の重要用語で復習できる、インストールして使える学習カードです。

クラウドの概念・設計、データセキュリティ、プラットフォーム/インフラ、アプリケーション、運用、法務・リスク・コンプライアンスの6ドメインを、短い直接想起、用語の識別、比較、実務判断で学びます。カードは前提から応用へドメイン順に進み、同じ概念の近似問題は離してあります。英語用語だけを答える機械的な逆方向、模擬試験、製品固有の操作は含みません。

2026年8月1日施行の公式CCSP Exam OutlineとISC2 Japanの試験案内を範囲確認に使用しました。すべて独自に作成した非公式教材で、ISC2の承認、提携、後援を受けていません。実際の試験問題、公式要綱の文面、市販ガイドの文面は転載していません。CCSP®はISC2, Inc.の登録商標です。

公式情報: CCSP Certification Exam Outline / ISC2 Japan CCSP認定試験

Κάρτες σε αυτήν τη δέσμη

  1. Κάρτα 1

    Ερώτηση

    クラウドコンピューティングを従来型ホスティングから区別する要点は?

    Απάντηση

    オンデマンドで共有された構成可能な資源を利用し、必要に応じて迅速に確保・解放できること。管理作業やプロバイダーとの個別調整を最小化する。

  2. Κάρτα 2

    Ερώτηση

    利用者が担当者を介さず、必要な計算資源を自動で確保できる特性は?

    Απάντηση

    オンデマンド・セルフサービス。利用者自身が必要な時点で資源をプロビジョニングできる。

  3. Κάρτα 3

    Ερώτηση

    標準的な仕組みで、PCやスマートフォンなど異なる端末からクラウドを利用できる特性は?

    Απάντηση

    広範なネットワークアクセス。多様なクライアントからネットワーク経由で利用できる。

  4. Κάρτα 4

    Ερώτηση

    複数テナント向けに物理・仮想資源を動的に割り当てる特性は?

    Απάντηση

    リソースプーリング。共有プールから需要に応じて資源を割り当てるため、テナント分離が重要になる。

  5. Κάρτα 5

    Ερώτηση

    需要の急増時に資源を素早く増やし、低下時に戻す特性は?

    Απάντηση

    迅速な弾力性(rapid elasticity)。需要に合わせて拡大と縮小を行う性質を指す。

  6. Κάρτα 6

    Ερώτηση

    クラウド利用量を自動計測し、課金や容量管理に使う特性は?

    Απάντηση

    測定サービス(measured service)。CPU、ストレージ、通信量などの利用を計測して可視化する。

  7. Κάρτα 7

    Ερώτηση

    IaaS上のIAM誤設定による事故で、利用者は「基盤はCSP管理」と責任を免れられる?

    Απάντηση

    免れない。共有責任モデルでは管理作業を分担しても、利用者側の設定とデータに対する説明責任は残る。

  8. Κάρτα 8

    Ερώτηση

    複数のクラウドサービスを選定・仲介・統合して利用者に提供する役割は?

    Απάντηση

    クラウドサービスブローカー。サービスの仲介、集約、選択支援などを担う。

  9. Κάρτα 9

    Ερώτηση

    クラウドサービスのセキュリティやプライバシー、性能を独立評価する役割は?

    Απάντηση

    クラウド監査人。利用者やプロバイダーから独立した立場で証拠と統制を評価する。

  10. Κάρτα 10

    Ερώτηση

    利用者とCSPの間のネットワーク接続を提供し、サービスを届ける役割は?

    Απάντηση

    クラウドキャリア。通信経路を提供し、クラウドサービスを利用者まで届ける。

  11. Κάρτα 11

    Ερώτηση

    法令や業界要件を定め、クラウド利用への適用を監督する役割は?

    Απάντηση

    規制当局。適用要件の解釈、監督、必要に応じた執行を担う。

  12. Κάρτα 12

    Ερώτηση

    予測される長期的な成長に合わせて処理能力を増やす性質は、弾力性とスケーラビリティのどちら?

    Απάντηση

    スケーラビリティ。継続的な負荷増加へ能力を拡張する性質で、短期需要に応じた増減を重視する弾力性とは焦点が違う。

  13. Κάρτα 13

    Ερώτηση

    仮想化とオーケストレーションの役割の違いは?

    Απάντηση

    仮想化は物理資源を論理資源として抽象化し、オーケストレーションは複数の資源や処理の配置・連携・運用を自動化する。

  14. Κάρτα 14

    Ερώτηση

    SaaSで利用者が主に管理するセキュリティ範囲は?

    Απάντηση

    データ、ID、アクセス権、利用可能な設定。アプリケーション本体、ランタイム、OS、基盤は主にCSPが管理する。

  15. Κάρτα 15

    Ερώτηση

    不特定多数の利用者へ共有基盤から提供される展開モデルは?

    Απάντηση

    パブリッククラウド。基盤はプロバイダーが運用し、複数の顧客が論理的に分離されて利用する。

  16. Κάρτα 16

    Ερώτηση

    異なるクラウドやシステムがデータを交換し、協調して動く能力は?

    Απάντηση

    相互運用性(interoperability)。移動のしやすさを指すポータビリティとは区別する。

  17. Κάρτα 17

    Ερώτηση

    仮想マシンとコンテナの主な分離境界の違いは?

    Απάντηση

    仮想マシンはそれぞれゲストOSを持ち、コンテナはホスト側のカーネルを共有する。コンテナでは共有カーネルの保護が特に重要になる。

  18. Κάρτα 18

    Ερώτηση

    PaaSで利用者が主に管理するものは?

    Απάντηση

    デプロイするアプリケーション、コード、データ、アプリ設定。ランタイム、ミドルウェア、OS、基盤は主にCSPが管理する。

  19. Κάρτα 19

    Ερώτηση

    単一組織専用として運用される展開モデルは?

    Απάντηση

    プライベートクラウド。組織内または外部事業者が運用しても、利用範囲はその組織に限定される。

  20. Κάρτα 20

    Ερώτηση

    アプリケーションやデータを別の環境へ移しやすい能力は?

    Απάντηση

    ポータビリティ(portability)。標準形式、移行手順、依存関係の把握が実現性を左右する。

  21. Κάρτα 21

    Ερώτηση

    SLAで最低限、測定方法まで明確にすべき項目は?

    Απάντηση

    サービスレベルの指標、目標値、測定範囲、報告方法、違反時の対応。曖昧な「高可用性」だけでは検証できない。

  22. Κάρτα 22

    Ερώτηση

    IaaSで利用者が主に管理するものは?

    Απάντηση

    ゲストOS、パッチ、アプリケーション、データ、ID、仮想ネットワーク設定。CSPは物理基盤と通常は仮想化層を管理する。

  23. Κάρτα 23

    Ερώτηση

    プライベートクラウドとパブリッククラウドを連携させる展開モデルは?

    Απάντηση

    ハイブリッドクラウド。異なる展開モデル間でデータやアプリケーションの移動・連携を設計する。

  24. Κάρτα 24

    Ερώτηση

    契約終了時にデータと処理を移し、依存を解消してサービスから退出できる能力は?

    Απάντηση

    可逆性(reversibility)。返却形式、削除、鍵、ログ、移行支援を退出計画で確認する。

  25. Κάρτα 25

    Ερώτηση

    機密コンピューティング(confidential computing)がクラウドで主に保護するデータ状態は?

    Απάντηση

    使用中のデータ(data in use)。TEEで処理中のメモリを隔離・保護し、リモートアテステーションで期待したコードと実行環境を確認してから秘密情報や鍵を渡す。保存中・転送中の保護は別途必要になる。

  26. Κάρτα 26

    Ερώτηση

    必要なときにサービスへアクセスできる性質は?

    Απάντηση

    可用性(availability)。稼働率だけでなく、依存サービスや接続を含めて必要時に利用できるかを扱う。

  27. Κάρτα 27

    Ερώτηση

    共通の使命や規制要件を持つ複数組織が共有する展開モデルは?

    Απάντηση

    コミュニティクラウド。参加組織に共通するセキュリティ、ポリシー、コンプライアンス要件を前提にする。

  28. Κάρτα 28

    Ερώτηση

    エッジやIoTをクラウドへ接続するとき、最初に見直す設計境界は?

    Απάντηση

    信頼境界。端末の物理保護、通信、認証、更新、データの所在まで攻撃面がクラウド外へ広がる。

  29. Κάρτα 29

    Ερώτηση

    ブロックチェーンの改ざん耐性が、自動では保護しないものは?

    Απάντηση

    秘密鍵、外部入力、台帳データの機密性。改ざん耐性があっても、盗まれた鍵による正規署名や誤った入力を検出・訂正せず、参加者に何を見せるかも別に設計する。

  30. Κάρτα 30

    Ερώτηση

    IaaS、PaaS、SaaSで共有責任の境界はどう変わる?

    Απάντηση

    利用者が管理する技術層はIaaSで広く、PaaS、SaaSの順に狭くなる。ただしデータ、ID、利用判断への利用者の責任は残る。

  31. Κάρτα 31

    Ερώτηση

    障害が起きても重要な機能を維持し、回復できる性質は?

    Απάντηση

    回復力(resilience)。単に停止しない可用性より、劣化運転、復旧、適応まで含む。

  32. Κάρτα 32

    Ερώτηση

    マルチクラウドとハイブリッドクラウドの違いは?

    Απάντηση

    マルチクラウドは複数のクラウドサービスを使う構成。ハイブリッドクラウドは異なる展開モデルを連携させ、一体として運用する構成。

  33. Κάρτα 33

    Ερώτηση

    量子技術が現在のクラウド暗号へ与える主要なリスクは?

    Απάντηση

    広く使われる公開鍵暗号(public-key cryptography)が将来破られるリスク。量子脆弱な鍵確立と署名を棚卸しし、NIST標準の耐量子計算機暗号(post-quantum cryptography: PQC)へ移行する計画を準備する。

  34. Κάρτα 34

    Ερώτηση

    クラウドIAMで最小権限を適用する対象は人だけ?

    Απάντηση

    人だけではない。ユーザー、管理者、サービスアカウント、ワークロードIDのすべてに必要最小限の権限と期間を設定する。

  35. Κάρτα 35

    Ερώτηση

    ワークロード単位で許可する通信元・宛先・ポートを制限する代表的なクラウド制御は?

    Απάντηση

    ネットワークセキュリティグループ。必要な通信だけを明示的に許可し、管理プレーンの変更も監査する。

  36. Κάρτα 36

    Ερώτηση

    接続元の地理条件でアクセスを許可・拒否する制御は?

    Απάντηση

    ジオフェンシング。位置情報だけに依存せず、ID、端末状態、通信検査などと組み合わせる。

  37. Κάρτα 37

    Ερώτηση

    クラウド暗号化で、鍵を暗号文と同じ管理境界に置く主な危険は?

    Απάντηση

    単一の侵害で暗号文と鍵の両方を奪われる危険。鍵の保管、利用権限、監査をデータから分離する。

  38. Κάρτα 38

    Ερώτηση

    クラウド上の媒体を再利用・廃棄するときのサニタイゼーション目標は?

    Απάντηση

    想定する労力では対象データへアクセスできない状態にすること。媒体、データ感度、残存コピーに合う方式と証拠を選ぶ。

  39. Κάρτα 39

    Ερώτηση

    ハイパーバイザー侵害が重大な理由は?

    Απάντηση

    複数の仮想マシンを隔離する境界だから。侵害されるとホスト上の複数テナントや管理機能へ影響が広がり得る。

  40. Κάρτα 40

    Ερώτηση

    エフェメラルまたはサーバーレス環境で「短命だから安全」と言えない理由は?

    Απάντηση

    設定、イメージ、権限、秘密情報、ログは実行時間を超えて影響を残すから。短命な資源にも安全な既定値と追跡性が必要になる。

  41. Κάρτα 41

    Ερώτηση

    公開ストレージを発見したときの最初の対応は?

    Απάντηση

    まず公開範囲を閉じる。その後、露出したデータ、アクセス履歴、認証情報、複製先を確認し、必要な通知と再発防止へ進む。

  42. Κάρτα 42

    Ερώτηση

    不変アーキテクチャがセキュリティハイジーンに役立つ理由は?

    Απάντηση

    稼働中の個別修正ではなく、検証済みイメージへ置き換えるため。構成ドリフトを減らし、パッチとベースラインを再現しやすい。

  43. Κάρτα 43

    Ερώτηση

    安全なクラウドデータライフサイクル設計で最初に決めるものは?

    Απάντηση

    データの種類、所有者、所在、処理目的、各段階の保護要件。作成から廃棄まで同じ分類を追跡できるようにする。

  44. Κάρτα 44

    Ερώτηση

    事業継続性(BC)と災害復旧(DR)の違いは?

    Απάντηση

    BCは中断中も重要業務を続ける全体計画。DRは停止したITサービスやデータを復旧するための計画。

  45. Κάρτα 45

    Ερώτηση

    BIAが復旧設計へ与える入力は?

    Απάντηση

    重要業務、中断の影響、復旧優先度、許容停止時間、データ損失許容度。技術構成より先に事業上の必要性を明らかにする。

  46. Κάρτα 46

    Ερώτηση

    高価な冗長構成を採用するか判断するとき、BIAと費用対効果分析をどう使う?

    Απάντηση

    BIAで中断損失と復旧要件を定め、そのリスク低減額と構成の総費用を比較する。ROIだけで法令や安全要件を無視しない。

  47. Κάρτα 47

    Ερώτηση

    ベンダーロックインを抑える機能要件の例は?

    Απάντηση

    標準形式でのデータ出力、API互換性、構成の移植性、鍵とログの返却、期限付きの移行支援、確認可能な削除。

  48. Κάρτα 48

    Ερώτηση

    クラウド設計で責任分担表を作る目的は?

    Απάντηση

    各制御の実施者、確認者、証拠、例外対応をサービスモデルごとに明確にすること。「CSPが対応」の思い込みによる空白を防ぐ。

  49. Κάρτα 49

    Ερώτηση

    セキュア・バイ・デザインの中心原則は?

    Απάντηση

    要件と設計の段階から安全性を組み込むこと。安全な既定値、最小権限、分離、失敗時の安全側動作を後付けにしない。

  50. Κάρτα 50

    Ερώτηση

    Well-Architectedなどの設計フレームワークを、そのまま認証証拠にできない理由は?

    Απάντηση

    設計判断を整理する枠組みであり、実装済み統制の独立保証ではないから。要件に合わせて適用し、構成・テスト・監査の証拠で確認する。

  51. Κάρτα 51

    Ερώτηση

    DevSecOpsでセキュリティを組み込む最も実務的な方法は?

    Απάντηση

    コード、IaC、依存関係、秘密情報、デプロイをCI/CD内で継続検査し、重大な違反を自動で止める。例外には所有者と期限を付ける。

  52. Κάρτα 52

    Ερώτηση

    CSPが「標準準拠」と説明したとき、評価で次に確認するものは?

    Απάντηση

    対象範囲、評価主体、有効期間、除外事項、顧客側の補完統制、最新の監査・認証証拠。ロゴや自己宣言だけでは足りない。

  53. Κάρτα 53

    Ερώτηση

    Common Criteria(CC)が主に評価するものは?

    Απάντηση

    IT製品やシステムの定義済みセキュリティ機能と、その評価保証。組織全体の運用が常に安全だと保証するものではない。

  54. Κάρτα 54

    Ερώτηση

    FIPS 140-2とFIPS 140-3の検証対象は?

    Απάντηση

    暗号モジュール。公式アウトラインはFIPS 140-2を挙げるが、CMVPはFIPS 140-3へ移行中で、FIPS 140-2検証モジュールは2026年9月21日まで新規システムに利用できる。調達時は証明書、版、状態、運用条件を確認する。

  55. Κάρτα 55

    Ερώτηση

    AIをクラウド脅威検出に使うとき、モデルの出力だけで自動遮断してよい?

    Απάντηση

    原則として影響に応じた検証が必要。検出精度、誤検知、見逃し、入力ドリフトを測り、高影響の判断には人の承認や安全な制限を置く。

  56. Κάρτα 56

    Ερώτηση

    AI/MLのデータソースで、妥当性確認(validation)と検証(verification)は何を分けて見る?

    Απάντηση

    妥当性確認では対象用途や母集団に適するかを見て、検証では出所、形式、完全性などが事前の要件を満たすかを見る。用途と要件を先に文書化する。

  57. Κάρτα 57

    Ερώτηση

    SOARがセキュリティ運用で担うものは?

    Απάντηση

    Security Orchestration, Automation and Response。複数ツールを連携し、定型的な調査・封じ込め手順を承認条件付きで自動化する。

  58. Κάρτα 58

    Ερώτηση

    AIをセキュリティ判断へ使う際の代表的な倫理上の確認事項は?

    Απάντηση

    不当な偏り、説明可能性、透明性、プライバシー、人への影響、異議申立て、最終責任。精度だけで採否を決めない。

  59. Κάρτα 59

    Ερώτηση

    AI/MLの規制要件をクラウド設計へ落とす最初の作業は?

    Απάντηση

    適用法域、用途、影響を受ける人、データ種類、提供者と利用者の役割を特定する。その上で記録、監督、評価、通知などの要件を統制へ割り当てる。

  60. Κάρτα 60

    Ερώτηση

    導入時に合格したAI脅威検出モデルを継続監視する理由は?

    Απάντηση

    データや攻撃手法の変化で性能とリスクが変わるから。ドリフト、誤検知、見逃し、偏りを測り、再評価とロールバック条件を保つ。

  61. Κάρτα 61

    Ερώτηση

    クラウドデータの作成段階で最初に付けるべき情報は?

    Απάντηση

    所有者、分類、処理目的、保持条件などのメタデータ。作成時に付けると、後続のアクセス制御やDLPへ引き継げる。

  62. Κάρτα 62

    Ερώτηση

    表形式の行・列や定義済みスキーマで管理されるデータは?

    Απάντηση

    構造化データ。データベースの列や型が明確で、規則的な検索や分類をしやすい。

  63. Κάρτα 63

    Ερώτηση

    長期保存ストレージで可用性以外に重視するものは?

    Απάντηση

    耐久性、保持期間、暗号鍵の寿命、形式の将来互換性、復元テスト、削除可能性。長く残るほど要件変更も考慮する。

  64. Κάρτα 64

    Ερώτηση

    実用的なデータ分類ポリシーに必要な要素は?

    Απάντηση

    分類レベル、判定基準、所有者、取り扱い規則、例外、再評価周期。ラベル名だけで終わらせず統制へ結び付ける。

  65. Κάρτα 65

    Ερώτηση

    クラウドデータの保存段階で中心となる統制は?

    Απάντηση

    保存先のアクセス制御、暗号化、鍵分離、冗長性、完全性確認、バックアップ。分類に応じて強度と保管場所を選ぶ。

  66. Κάρτα 66

    Ερώτηση

    文書、画像、音声のように固定スキーマを持たないデータは?

    Απάντηση

    非構造化データ。内容解析やメタデータを使わないと、機密情報の発見と分類が難しい。

  67. Κάρτα 67

    Ερώτηση

    オブジェクトストレージが向くデータと主な管理単位は?

    Απάντηση

    画像、バックアップ、ログなどの非構造化データに向き、オブジェクト、メタデータ、バケットポリシーを単位に管理する。

  68. Κάρτα 68

    Ερώτηση

    データマッピングで明らかにするものは?

    Απάντηση

    データ項目、分類、所有者、取得元、処理、保存先、共有先、法域、保持期間の対応関係。データフローと統制の空白を見つける。

  69. Κάρτα 69

    Ερώτηση

    クラウドデータの利用段階で特に必要な保護は?

    Απάντηση

    処理権限の最小化、使用中データの保護、操作ログ、目的外利用の防止。正当な閲覧権限がある利用者にも用途制限を適用する。

  70. Κάρτα 70

    Ερώτηση

    JSONやXMLのように自己記述的な構造を持つデータは?

    Απάντηση

    半構造化データ。固定表ではないが、キーやタグが構造と意味を示す。

  71. Κάρτα 71

    Ερώτηση

    一時ストレージへ重要データを置く際の最大の注意点は?

    Απάντηση

    インスタンス停止や再作成で失われ得ること。永続化が必要なデータは別の耐久ストレージへ移し、秘密情報や残存データも管理する。

  72. Κάρτα 72

    Ερώτηση

    分類ラベルとタグの役割は?

    Απάντηση

    データの分類結果を機械と人が扱える形で示し、アクセス制御、暗号化、DLP、保持、監視のポリシー適用に使う。

  73. Κάρτα 73

    Ερώτηση

    クラウドデータの共有段階で確認するものは?

    Απάντηση

    受信者、目的、最小範囲、転送保護、再共有条件、有効期限、契約と法域。共有後も追跡と失効が可能かを確認する。

  74. Κάρτα 74

    Ερώτηση

    データディスカバリーで物理・論理的な所在を確認する理由は?

    Απάντηση

    法域、アクセス経路、複製、暗号鍵、削除責任が所在によって変わるから。リージョン名だけで全コピーの場所を決めつけない。

  75. Κάρτα 75

    Ερώτηση

    仮想マシンへ永続的なブロックデバイスとして接続するストレージは?

    Απάντηση

    ボリュームストレージ。ファイルシステムやデータベース向けだが、スナップショット、暗号化、アタッチ権限も管理する。

  76. Κάρτα 76

    Ερώτηση

    IRMの目的は?

    Απάντηση

    情報に対する利用権を継続的に制御すること。閲覧、編集、印刷、転送、期限などをデータと結び付ける。

  77. Κάρτα 77

    Ερώτηση

    クラウドデータのアーカイブ段階で確認するものは?

    Απάντηση

    保持根拠、検索性、完全性、暗号鍵、形式の可読性、アクセス制限、期限後の削除。復元できない保管は有効なアーカイブではない。

  78. Κάρτα 78

    Ερώτηση

    データディスカバリーの成果物は単なるファイル一覧?

    Απάντηση

    違う。機密データの所在、種類、所有者、分類候補、処理経路を含む在庫として、保護と是正の判断に使う。

  79. Κάρτα 79

    Ερώτηση

    ローストレージを直接利用するときの主なリスクは?

    Απάντηση

    ファイルシステム等の上位保護がなく、消去、アクセス制御、整合性、スナップショット管理を利用者側で正しく設計する必要があること。

  80. Κάρτα 80

    Ερώτηση

    データ分類の最終責任を持つ役割は?

    Απάντηση

    データ所有者。分類基準に基づいて決定し、事業価値や規制が変われば定期的に見直す。ツールの推定だけに委ねない。

  81. Κάρτα 81

    Ερώτηση

    クラウドデータの破棄段階で必要な完了条件は?

    Απάντηση

    本体、複製、キャッシュ、スナップショット、バックアップ、鍵を対象に、保持義務や法的保全を満たしたうえで復元不能性を確認すること。

  82. Κάρτα 82

    Ερώτηση

    データディスカバリーを継続実行する理由は?

    Απάντηση

    新しいデータ、複製、SaaS、シャドーITが日々増え、在庫がすぐ古くなるから。変更検知と定期スキャンを是正フローへつなぐ。

  83. Κάρτα 83

    Ερώτηση

    クラウドストレージで種類を問わず最初に疑う共通脅威は?

    Απάντηση

    誤設定と過剰権限。公開設定、共有リンク、サービスID、管理API、スナップショットの権限を一体で確認する。

  84. Κάρτα 84

    Ερώτηση

    IRMがファイル共有後も有効であるために必要な性質は?

    Απάντηση

    権利が情報と結び付き、利用時に認証・認可を再評価できること。保存場所を移しても期限や操作制限を適用する。

  85. Κάρτα 85

    Ερώτηση

    データ分散が可用性を高めても、新たに生むセキュリティ課題は?

    Απάντηση

    コピーと断片の所在、法域、鍵、削除、アクセス経路が増えること。全配置を把握し、一貫した統制を適用する。

  86. Κάρτα 86

    Ερώτηση

    クラウドストレージ種別を選ぶ判断軸は?

    Απάντηση

    耐久性、性能、共有方法、データ構造、保持、復旧、暗号化、削除、料金。名称ではなく要件と脅威に合わせて選ぶ。

  87. Κάρτα 87

    Ερώτηση

    データ分類を実際の保護へ変えるには?

    Απάντηση

    各分類をアクセス、暗号化、共有、DLP、ログ、保持、削除の具体的な統制へ対応付ける。ラベルだけではリスクは下がらない。

  88. Κάρτα 88

    Ερώτηση

    IRMで権利をプロビジョニング・失効する基本手順は?

    Απάντηση

    対象IDへ最小限の権利と期限を発行し、役割変更、契約終了、侵害時に失効する。失効情報が利用時に反映されることも確認する。

  89. Κάρτα 89

    Ερώτηση

    データフロー図に最低限含めるものは?

    Απάντηση

    取得元、処理、保存先、転送先、信頼境界、プロトコル、データ分類、管理主体。境界を越える箇所に統制を割り当てる。

  90. Κάρτα 90

    Ερώτηση

    保存データ(data at rest)の基本的な暗号化設計は?

    Απάντηση

    保存媒体を暗号化し、鍵を分離して管理する。暗号化範囲、スナップショット、バックアップ、復旧時の鍵利用まで確認する。

  91. Κάρτα 91

    Ερώτηση

    データ保持期間は「長いほど安全」?

    Απάντηση

    違う。法令、契約、業務目的、訴訟対応、リスクを根拠に必要期間だけ保持し、期限後は法的保全がない限り削除する。

  92. Κάρτα 92

    Ερώτηση

    データイベントの監査可能性とは?

    Απάντηση

    後から独立して事実と統制の実施状況を評価できること。十分なログ、保護された証拠、検索性、保持が必要になる。

  93. Κάρτα 93

    Ερώτηση

    本番データを閲覧者ごとに隠して表示しつつ、元データを変えない保護手法は?

    Απάντηση

    動的データマスキング。閲覧時の表示を隠すが、基礎データ自体は残るため、保存時の暗号化やアクセス制御も必要。

  94. Κάρτα 94

    Ερώτηση

    AIのデータセットとモデルのプライバシーを守る基本方針は?

    Απάντηση

    必要なデータだけを収集し、用途、アクセス、保持、出力を制限する。匿名化や集約などの手法も、再識別と精度への影響を評価して使う。

  95. Κάρτα 95

    Ερώτηση

    アーカイブとバックアップの違いは?

    Απάντηση

    アーカイブは長期保持と参照のため、バックアップは障害から復旧するためのコピー。目的、検索性、更新頻度、保持期間が異なる。

  96. Κάρτα 96

    Ερώτηση

    CSPへ鍵素材を持ち込めば、CSP管理者から平文を必ず分離できる?

    Απάντηση

    必ずしもできない。鍵の由来だけでなく、復号処理の場所、鍵利用権限、管理者権限、監査境界を確認する。

  97. Κάρτα 97

    Ερώτηση

    データイベントの追跡可能性とは?

    Απάντηση

    データの作成、変更、移動、共有、削除を、時刻と主体を保った連続した履歴としてたどれること。相関IDが分散処理の追跡に役立つ。

  98. Κάρτα 98

    Ερώτηση

    学習前のデータセットの妥当性確認(validation)で確認するものは?

    Απάντηση

    目的への適合性、代表性、品質、許可された取得、ラベル、重複、汚染、既知の偏り。基準を満たさないデータは学習へ入れない。

  99. Κάρτα 99

    Ερώτηση

    転送中データ(data in transit)の基本的な保護は?

    Απάντηση

    証明書と通信相手を検証するTLS。経路上の機密性と完全性を守り、古いプロトコルや証明書検証の無効化を避ける。相互TLSは双方の証明書認証が必要な場合に追加する。

  100. Κάρτα 100

    Ερώτηση

    法的保全(legal hold)が発令されたら通常の削除期限をどう扱う?

    Απάντηση

    対象データの削除を停止する。許可された担当者だけが範囲を管理し、保全理由、開始・解除、アクセスを記録する。

  101. Κάρτα 101

    Ερώτηση

    暗号鍵を定期ローテーションする主な目的は?

    Απάντηση

    1つの鍵で保護するデータ量と侵害時の影響期間を抑えること。旧データの復号、再暗号化、失効、バックアップ鍵も計画する。

  102. Κάρτα 102

    Ερώτηση

    機密値を非機密の置換値へ変え、別の安全な対応表で元に戻せる方式は?

    Απάντηση

    トークン化。トークン自体から元データを数学的に復元せず、対応表またはトークンサービスを分離して守る。

  103. Κάρτα 103

    Ερώτηση

    学習後のモデルを検証(verification)するときの基準は?

    Απάντηση

    事前に定めた機能、安全性、性能、再現性の要件や仕様。承認済みの試験と記録で適合を確認し、特定用途への適合性を扱う妥当性確認とは区別する。

  104. Κάρτα 104

    Ερώτηση

    クラウド上の削除API成功だけで安全な削除を証明できる?

    Απάντηση

    できない。削除の意味、猶予期間、複製、スナップショット、バックアップ、鍵、物理媒体の処理を契約と証拠で確認する。

  105. Κάρτα 105

    Ερώτηση

    ハッシュ値の比較で確認できる代表的な性質は?

    Απάντηση

    完全性。同じ入力から同じハッシュ値を得る性質を使い、保存・転送中の変更を検知する。比較元のハッシュも保護する。

  106. Κάρτα 106

    Ερώτηση

    データイベントログに最低限必要な属性は?

    Απάντηση

    誰が、いつ、どこから、どのデータへ、何を行い、結果がどうなったか。ID、時刻、送信元、対象、操作、成否を相関できるようにする。

  107. Κάρτα 107

    Ερώτηση

    学習データのポイズニングを検知・抑制する基礎は?

    Απάντηση

    出所と変更履歴を保ち、信頼できる取得元、完全性確認、異常検査、承認を通すこと。モデル性能だけでデータの正当性を判断しない。

  108. Κάρτα 108

    Ερώτηση

    エンベロープ暗号化の構造は?

    Απάντηση

    データ鍵でデータを暗号化し、そのデータ鍵を別の鍵暗号化鍵で包む構造。大量データを再暗号化せず上位鍵を管理しやすい。

  109. Κάρτα 109

    Ερώτηση

    暗号消去(cryptographic erase)が有効になる条件は?

    Απάντηση

    対象コピーが強い暗号で保護され、復号に必要な鍵の全コピーを回復不能に破棄できること。平文コピーや別鍵の複製が残れば完了しない。

  110. Κάρτα 110

    Ερώτηση

    分散クラウドのログで改ざん耐性と時刻同期が重要な理由は?

    Απάντηση

    イベント順序と証拠の信頼性を保つため。集中保管、書込み制限、完全性検証、共通時刻源で後からの改変と時系列の崩れを抑える。

  111. Κάρτα 111

    Ερώτηση

    DLPが主に検知・制御するものは?

    Απάντηση

    機密データの保存、利用、転送におけるポリシー違反。内容、文脈、分類ラベルを使い、警告、遮断、隔離、暗号化などを行う。

  112. Κάρτα 112

    Ερώτηση

    モデル反転とモデル抽出の違いは?

    Απάντηση

    モデル反転は出力から学習データの特徴や情報を推定し、モデル抽出は問い合わせ結果からモデルの機能や近似コピーを得ようとする。

  113. Κάρτα 113

    Ερώτηση

    高価値鍵へ知識分割(split knowledge)または二重統制(dual control)を使う目的は?

    Απάντηση

    1人だけでは鍵全体を知ったり重要操作を完了したりできないようにすること。内部不正と単一担当者の侵害リスクを下げる。

  114. Κάρτα 114

    Ερώτηση

    匿名化と仮名化の違いは?

    Απάντηση

    匿名化は合理的な手段で個人へ再結合できない状態を目指す。仮名化は対応情報を分離するが、追加情報があれば再結合できる。

  115. Κάρτα 115

    Ερώτηση

    証拠保全の連続性(chain of custody)を示すために記録するものは?

    Απάντηση

    収集者、日時、場所、方法、ハッシュ、受渡し、保管、アクセス、変更。証拠が誰の管理下にあり、完全性が保たれたかを連続して示す。

  116. Κάρτα 116

    Ερώτηση

    機密データが誤って「公開」とラベル付けされた場合の主な失敗は?

    Απάντηση

    下流の自動統制が弱い分類を信頼し、共有、暗号化、DLP、保持を誤適用すること。高リスク判定には検証と例外検知を加える。

  117. Κάρτα 117

    Ερώτηση

    使用中データ(data in use)の露出を減らす代表的な方法は?

    Απάντηση

    処理権限とメモリアクセスを最小化し、必要に応じて信頼実行環境などを使う。保存時・転送時の暗号化だけでは処理中の平文を守れない。

  118. Κάρτα 118

    Ερώτηση

    本体データを削除したのに復元できる典型的な理由は?

    Απάντηση

    レプリカ、スナップショット、キャッシュ、バックアップが別の保持周期で残るため。全コピーの削除または期限付き失効を追跡する。

  119. Κάρτα 119

    Ερώτηση

    デジタル署名が否認防止に役立つ理由は?

    Απάντηση

    署名者の秘密鍵による署名を公開鍵で検証し、出所と完全性を結び付けられるから。鍵の本人性、保護、失効、時刻の証拠も必要になる。

  120. Κάρτα 120

    Ερώτηση

    APIキーやパスワードなどの秘密情報をコードへ埋め込まない代替策は?

    Απάντηση

    専用のシークレット管理サービスへ保管し、ワークロードIDで実行時に必要分だけ取得する。ローテーションと利用監査も行う。

  121. Κάρτα 121

    Ερώτηση

    IRMで証明書の発行と失効が果たす役割は?

    Απάντηση

    利用者や端末の信頼を確認し、暗号鍵や権利の利用可否を制御する。失効後に既存コピーへどう反映するかも設計する。

  122. Κάρτα 122

    Ερώτηση

    長期アーカイブで暗号化だけでは不十分な理由は?

    Απάντηση

    将来も形式を読め、鍵を安全に復旧し、完全性を検証し、必要な期間内に検索できなければ利用できないから。定期的に復元を試す。

  123. Κάρτα 123

    Ερώτηση

    ハッシュだけで否認防止を実現できる?

    Απάντηση

    できない。ハッシュは変更検知に使えるが、誰が作成・承認したかを証明しない。署名、本人確認、鍵管理、監査記録が必要になる。

  124. Κάρτα 124

    Ερώτηση

    法令、契約、業務の保持期間が衝突したときの判断原則は?

    Απάντηση

    適用範囲と優先関係を法務・データ所有者と確認する。一律に最長期間を選ばず、保持義務、削除義務、法的保全を両立する承認済みルールへ統合する。

  125. Κάρτα 125

    Ερώτηση

    クラウド証明書管理で自動化すべきライフサイクルは?

    Απάντηση

    発行、配布、更新、ローテーション、失効、期限監視。秘密鍵を保護し、失効や期限切れが各サービスへ反映されることを確認する。

  126. Κάρτα 126

    Ερώτηση

    IRMとIAMの違いは?

    Απάντηση

    IAMは主体がシステムや資源へアクセスできるかを制御する。IRMは取得後の情報に対する閲覧、編集、印刷、転送、期限なども制御する。

  127. Κάρτα 127

    Ερώτηση

    CSPによるデータ削除を確認する証拠の例は?

    Απάντηση

    削除ログや証明、対象範囲、完了時刻、バックアップ失効条件、媒体処理の手順、契約上の監査権。単独の証明書だけで範囲を推測しない。

  128. Κάρτα 128

    Ερώτηση

    データイベントの説明責任を成立させる条件は?

    Απάντηση

    操作を責任ある主体へ帰属させ、権限、判断、結果をレビューできること。共有IDを避け、個別IDと承認・監査の記録を保つ。

  129. Κάρτα 129

    Ερώτηση

    クラウド基盤を構成する主要な6領域は?

    Απάντηση

    物理環境、ネットワーク/通信、コンピューティング、仮想化、ストレージ、管理プレーン。各領域に固有の障害点と制御がある。

  130. Κάρτα 130

    Ερώτηση

    データセンターの立地選定で最初に確認するリスクは?

    Απάντηση

    地域固有の脅威。洪水、地震、山火事、停電、治安、交通、規制を事業要件と照合する。

  131. Κάρτα 131

    Ερώτηση

    脅威・脆弱性・資産の関係として、リスクが成立する条件は?

    Απάντηση

    価値ある資産に対し、脅威が脆弱性を悪用して損失を生む可能性があること。脅威だけ、または脆弱性だけでは事業リスクを評価できない。

  132. Κάρτα 132

    Ερώτηση

    単一の防御が破られても侵害を止める設計原則は?

    Απάντηση

    多層防御(defense in depth)。独立した予防・検知・対応制御を重ね、単一障害点を減らす。

  133. Κάρτα 133

    Ερώτηση

    BCとDRの最短の違いは?

    Απάντηση

    BC(Business Continuity)は重要業務の継続、DR(Disaster Recovery)は中断したIT機能の復旧に重点を置く。

  134. Κάρτα 134

    Ερώτηση

    クラウド資源の作成・変更・削除を指揮する面は?

    Απάντηση

    管理プレーン(management/control plane)。侵害されると多数のデータプレーン資源へ横断的な影響が及ぶ。

  135. Κάρτα 135

    Ερώτηση

    マルチテナント環境の論理設計で最優先の分離対象は?

    Απάντηση

    テナントごとのデータ、処理、ID、管理操作。共有基盤でも別テナントから参照・干渉できない境界を設ける。

  136. Κάρτα 136

    Ερώτηση

    脅威と脆弱性の違いは?

    Απάντηση

    脅威は損害を起こし得る主体・事象、脆弱性は悪用され得る弱点。攻撃は脅威が弱点を利用する具体的な行為である。

  137. Κάρτα 137

    Ερώτηση

    認証と認可の順序と役割は?

    Απάντηση

    認証(authentication)で主体を確かめ、認可(authorization)で許可する操作を決める。識別は主体が名乗る段階である。

  138. Κάρτα 138

    Ερώτηση

    復旧優先順位と停止影響を決める分析は?

    Απάντηση

    BIA(Business Impact Analysis)。重要業務、依存関係、時間経過による影響、復旧目標を明らかにする。

  139. Κάρτα 139

    Ερώτηση

    複数のVMへ物理資源を割り当て、隔離を仲介する層は?

    Απάντηση

    ハイパーバイザー(VMM)。CPU、メモリ、ネットワーク、ストレージへのアクセスを仲介するため、高価値な防御対象になる。

  140. Κάρτα 140

    Ερώτηση

    データセンターの物理アクセスを段階的に絞る設計は?

    Απάντηση

    ゾーン化された物理防御。敷地、建物、フロア、ケージ、ラックへ進むほど認可を厳しくし、入退室を記録する。

  141. Κάρτα 141

    Ερώτηση

    リスク評価で組み合わせる2つの軸は?

    Απάντηση

    発生可能性(likelihood)と影響(impact)。資産価値、既存制御、脅威情報を踏まえて優先順位を付ける。

  142. Κάρτα 142

    Ερώτηση

    管理者権限の漏えい時の被害範囲を最小化する原則は?

    Απάντηση

    最小権限。業務に必要な操作だけを、必要な範囲と時間に限定して付与する。

  143. Κάρτα 143

    Ερώτηση

    RTOが表すものは?

    Απάντηση

    許容されるサービス停止時間の目標。中断から復旧までに許される時間を示す。

  144. Κάρτα 144

    Ερώτηση

    VMとコンテナの隔離境界の違いは?

    Απάντηση

    VMは通常ゲストOSごと分離し、コンテナはホストOSのカーネルを共有する。コンテナではカーネルとランタイムの防御が特に重要になる。

  145. Κάρτα 145

    Ερώτηση

    データセンターで電源と冷却を同時に冗長化する理由は?

    Απάντηση

    どちらの停止も計算資源を利用不能にするため。独立した電源系統、UPS/発電機、冗長HVACを障害シナリオに合わせる。

  146. Κάρτα 146

    Ερώτηση

    クラウドで管理プレーンが高価値な攻撃面になる理由は?

    Απάντηση

    少数の資格情報やAPIが多数の資源を制御できるため。管理経路を業務トラフィックから分離し、強い認証と監査を適用する。

  147. Κάρτα 147

    Ερώτηση

    特権操作にMFAを優先する理由は?

    Απάντηση

    単一の資格情報が盗まれても管理操作を成立させにくくするため。フィッシング耐性のある方式なら、偽サイトへの耐性も高められる。

  148. Κάρτα 148

    Ερώτηση

    RPOが表すものは?

    Απάντηση

    許容されるデータ損失量の時間目標。復旧時点を障害発生前のどこまで戻せるべきかを示す。

  149. Κάρτα 149

    Ερώτηση

    仮想スイッチ内だけを流れる通信で起こりやすい監視上の盲点は?

    Απάντηση

    物理ネットワーク機器を通らず、従来の監視点から見えないこと。仮想ネットワーク側にもフロー記録や検査点を置く。

  150. Κάρτα 150

    Ερώτηση

    回線を二重化しても同じ管路を通る場合に残る問題は?

    Απάντηση

    共通原因障害。通信事業者だけでなく、物理経路、引込口、終端装置も分離して経路多様性を確保する。

  151. Κάρτα 151

    Ερώτηση

    VM escapeとは?

    Απάντηση

    ゲストVM内の攻撃者が仮想化境界を越え、ハイパーバイザーや他のVMへ到達する攻撃。隔離破りとして扱う。

  152. Κάρτα 152

    Ερώτηση

    侵害後の横移動と爆発半径を抑えるネットワーク制御は?

    Απάντηση

    セグメンテーション/マイクロセグメンテーション。通信を業務上必要な送信元・宛先・サービスに限定する。

  153. Κάρτα 153

    Ερώτηση

    MTD/MAOがRTOより長くなければならない理由は?

    Απάντηση

    最大許容停止時間の前に復旧を完了する必要があるため。RTOは復旧目標、MTD/MAOは事業が耐えられる停止の上限である。

  154. Κάρτα 154

    Ερώτηση

    クラウドストレージを保護する基本制御の組み合わせは?

    Απάντηση

    アクセス制御、暗号化、完全性確認、バックアップ、監査ログ、ライフサイクル管理。ストレージ種別とデータ分類に合わせる。

  155. Κάρτα 155

    Ερώτηση

    可用性設計で障害ドメインを分ける目的は?

    Απάντηση

    単一障害で全レプリカが同時停止しないようにすること。電源、ネットワーク、ラック、ゾーン、リージョンの共有点を確認する。

  156. Κάρτα 156

    Ερώτηση

    hyperjackingが狙う対象は?

    Απάντηση

    ハイパーバイザー。不正なハイパーバイザーへの置換や制御奪取により、複数ゲストを下層から監視・操作する。

  157. Κάρτα 157

    Ερώτηση

    保存時暗号化と通信時暗号化が別々に必要な理由は?

    Απάντηση

    保護する状態と経路が異なるため。保存時は媒体やスナップショット、通信時は盗聴や改ざんのリスクを主に抑える。

  158. Κάρτα 158

    Ερώτηση

    冗長化とバックアップの違いは?

    Απάντηση

    冗長化は稼働継続、バックアップは過去時点のデータ復元が主目的。誤削除や破損は冗長系にも複製され得る。

  159. Κάρτα 159

    Ερώτηση

    監査ログに最低限ひも付けたい事実は?

    Απάντηση

    誰が、いつ、どこから、何に、どの操作を行い、結果がどうなったか。時刻同期と改ざん防止も必要になる。

  160. Κάρτα 160

    Ερώτηση

    温度・湿度・漏水センサーを独立監視する目的は?

    Απάντηση

    設備障害がIT停止へ進む前に検知するため。しきい値、通知先、対応手順まで設計して初めて制御として機能する。

  161. Κάρτα 161

    Ερώτηση

    共有CPUキャッシュなどを悪用して別処理の情報を推測する攻撃は?

    Απάντηση

    サイドチャネル攻撃。論理的なアクセス制御を破らず、共有資源の時間差や挙動から秘密を推測する。

  162. Κάρτα 162

    Ερώτηση

    複数AZと複数リージョンの使い分けは?

    Απάντηση

    複数AZは主に局所的な設備障害、複数リージョンは広域障害への耐性を高める。後者は遅延、整合性、費用、法域の検討が増える。

  163. Κάρτα 163

    Ερώτηση

    複数サービスのログを相関させる価値は?

    Απάντηση

    単独イベントでは見えない攻撃経路を時系列と主体で結び付けられること。共通時刻と一貫した識別子が精度を支える。

  164. Κάρτα 164

    Ερώτηση

    マルチテナント基盤のnoisy neighborリスクとは?

    Απάντηση

    他テナントの過剰利用が共有資源を圧迫し、自テナントの性能や可用性を落とすこと。クォータ、制限、分離、監視で抑える。

  165. Κάρτα 165

    Ερώτηση

    データセンターの火災対策で、人命保護に次いで重視する設計判断は?

    Απάντηση

    火災を早期検知し、設備に適した方式で延焼を抑えること。消火方式は人員、機器、地域規制との整合が必要になる。

  166. Κάρτα 166

    Ερώτηση

    クラウド侵害で設定ミスが大きなリスクになりやすい理由は?

    Απάντηση

    APIで広範囲へ素早く複製され、公開範囲や権限を一度に誤れるため。安全な既定値、レビュー、ポリシー検査で予防する。

  167. Κάρτα 167

    Ερώτηση

    パケットキャプチャを監査に使う際の主な限界は?

    Απάντηση

    暗号化された内容はそのまま読めず、量と機密性の負担も大きいこと。目的、取得点、保持期間、アクセス権を限定する。

  168. Κάρτα 168

    Ερώτηση

    ホット・ウォーム・コールド復旧サイトの違いは?

    Απάντηση

    ホットは即時に近い稼働、ウォームは一部準備済み、コールドは施設中心で構築が必要。復旧速度が上がるほど通常は費用も上がる。

  169. Κάρτα 169

    Ερώτηση

    管理プレーンとデータプレーンの最短の違いは?

    Απάντηση

    管理プレーンは資源の構成を指揮し、データプレーンは実際の業務トラフィックや処理を運ぶ。制御と監視を分けて考える。

  170. Κάρτα 170

    Ερώτηση

    廃棄媒体から暗号化データを読めなくする有効な方法は?

    Απάντηση

    暗号消去(cryptographic erase)。対象データを暗号化していた鍵を安全に破棄し、復号不能にする。鍵管理が前提となる。

  171. Κάρτα 171

    Ερώτηση

    共有基盤の資源枯渇攻撃を抑える制御は?

    Απάντηση

    クォータ、レート制限、予約容量、オートスケール上限、監視。可用性だけでなく、予期しない費用増加も考慮する。

  172. Κάρτα 172

    Ερώτηση

    ゼロトラストで、社内ネットワーク上という理由だけでは与えないものは?

    Απάντηση

    暗黙の信頼。ユーザー、端末、ワークロードの状態を基に、資源アクセスごとに認証・認可する。

  173. Κάρτα 173

    Ερώτηση

    failoverとfailbackの違いは?

    Απάντηση

    failoverは待機系への切替、failbackは復旧した通常系へ安全に戻す処理。データ同期と切戻し条件を事前に定める。

  174. Κάρτα 174

    Ερώτηση

    VMイメージやテンプレートを本番展開前に保護する基本策は?

    Απάντηση

    承認済みの強化済みイメージを署名・スキャンし、変更を追跡すること。古い脆弱性や秘密を複製しない。

  175. Κάρτα 175

    Ερώτηση

    離れたDR拠点でも同じ洪水域や電力網なら残るリスクは?

    Απάντηση

    地理的相関のある共通原因障害。距離だけでなく、災害域、電力、通信、交通、法域の独立性を確認する。

  176. Κάρτα 176

    Ερώτηση

    ISC2 2026が示すリスク対応の5つの選択肢は?

    Απάντηση

    回避(avoid)、低減(mitigate)、移転(transfer)、共有(share)、受容(accept)。NISTもこの5つを基本的なリスク対応として区別する。

  177. Κάρτα 177

    Ερώτηση

    クラウド構成の意図しない変更を検知する基準は?

    Απάντηση

    承認済みセキュリティベースライン。実状態との差分を監視し、誰が何を変更したか追跡できるようにする。

    中央の保護されたクラウドと、周囲で連携する6つのセキュリティ領域を描いた抽象図

    354 κάρτες

    CCSP 2026 試験対策フラッシュカード:6ドメイン総復習

    Μελετήστε αυτήν τη δέσμη δωρεάν

    Το Nibomo ανοίγει για να ξεκινήσετε τη μελέτη.

  178. Κάρτα 178

    Ερώτηση

    同期レプリケーションだけではランサムウェア対策にならない理由は?

    Απάντηση

    暗号化や破損も即座に複製され得るため。分離され、世代管理され、復元確認済みのバックアップを併用する。

  179. Κάρτα 179

    Ερώτηση

    north-south通信とeast-west通信の違いは?

    Απάντηση

    north-southは環境境界を出入りする通信、east-westは内部サービス間の通信。両方に可視化と適切な制御が必要である。

  180. Κάρτα 180

    Ερώτηση

    クラウド利用者がCSP施設へ自由に入れない場合、物理統制をどう確認する?

    Απάντηση

    契約、独立監査報告、認証、証跡で保証を得る。直接立入できないことを、統制が不要という意味にしない。

  181. Κάρτα 181

    Ερώτηση

    残余リスクとは?

    Απάντηση

    制御適用後も残るリスク。ゼロになるとは限らないため、許容度との比較、責任者の判断、継続監視が必要になる。

  182. Κάρτα 182

    Ερώτηση

    人の長期資格情報をサービス間通信に流用しない代替策は?

    Απάντηση

    ワークロードIDと短命な資格情報。サービス自身を認証し、対象と期限を絞った権限を与える。

  183. Κάρτα 183

    Ερώτηση

    BC/DR計画を文書レビューだけで終わらせない理由は?

    Απάντηση

    実行可能性、依存関係、権限、連絡、復旧時間は演習でしか確かめにくいため。机上、技術復旧、切替など段階的に試す。

  184. Κάρτα 184

    Ερώτηση

    不変インフラストラクチャで障害ノードを直す代わりに行うことは?

    Απάντηση

    承認済みイメージから置き換える。個別修正による構成ずれを減らし、再現可能な復旧につなげる。

  185. Κάρτα 185

    Ερώτηση

    監査証跡の否認防止を強める設計は?

    Απάντηση

    ログを集中保管し、書込み権限を分離し、完全性を検証し、時刻を同期すること。管理者自身の操作も記録する。

  186. Κάρτα 186

    Ερώτηση

    復旧サービスレベルを実行可能な手順へ落とす文書は?

    Απάντηση

    DRランブック。起動順序、依存関係、担当、判定基準、連絡、検証、切戻しを具体化する。

  187. Κάρτα 187

    Ερώτηση

    データセンターのbuy(既存施設・サービスの利用)とbuild(自社での構築・運用)は、何を基準に選ぶ?

    Απάντηση

    必要なセキュリティ・プライバシー要件、統制を直接管理する必要性、責任分担と保証、ライフサイクル全体の費用、運用能力。buyでは事業者の能力と契約・SLA・独立評価を確認し、buildでは施設の防御と可用性を自ら継続運用できるかを確かめる。

  188. Κάρτα 188

    Ερώτηση

    アプリケーションセキュリティ教育を役割別にする理由は?

    Απάντηση

    開発者、設計者、テスター、運用者で必要な判断と失敗パターンが異なるため。各役割の実作業に結び付ける。

  189. Κάρτα 189

    Ερώτηση

    安全なSDLCで、機能要件と同時に定義するものは?

    Απάντηση

    検証可能なセキュリティ要件。保護対象、脅威、アクセス、ログ、暗号、可用性、受入基準を具体化する。

  190. Κάρτα 190

    Ερώτηση

    脅威モデリングの4つの基本質問は?

    Απάντηση

    何を作るか、何が起こり得るか、どう対処するか、十分に対処できたか。設計変更に合わせて繰り返す。

  191. Κάρτα 191

    Ερώτηση

    機能テストと非機能テストの違いは?

    Απάντηση

    機能テストは期待した処理結果、非機能テストは性能・可用性・セキュリティなどの品質特性を確認する。

  192. Κάρτα 192

    Ερώτηση

    クラウドで、共有基盤の隔離不備から他テナントへ影響が及ぶリスクは?

    Απάντηση

    共有技術の問題。ハイパーバイザー、仮想ネットワーク、共有ストレージなどの分離が破られると、テナント間の情報漏えいや干渉につながる。

  193. Κάρτα 193

    Ερώτηση

    第三者製・オープンソースソフトウェアの検証で確認する代表的な要素は?

    Απάντηση

    出所、完全性、真正性、既知脆弱性、保守状況、ライセンス。有名であることだけでは足りない。

  194. Κάρτα 194

    Ερώτηση

    WAFが主に検査する場所は?

    Απάντηση

    WebアプリケーションへのHTTP(S)要求と応答。一般的なWeb攻撃を遮断できるが、安全なコードの代替ではない。

  195. Κάρτα 195

    Ερώτηση

    IDフェデレーションの目的は?

    Απάντηση

    異なる信頼領域の間で、認証結果や属性を信頼して利用できるようにすること。信頼関係とアサーション検証が要点になる。

  196. Κάρτα 196

    Ερώτηση

    クラウド開発で「CSPが全部守る」という思い込みが危険な理由は?

    Απάντηση

    責任共有モデルでは顧客側に残る設定、ID、データ、アプリケーションの責任があるため。サービスモデルごとに境界を確認する。

  197. Κάρτα 197

    Ερώτηση

    ウォーターフォールとアジャイルで、セキュリティ活動の置き方はどう変わる?

    Απάντηση

    ウォーターフォールでは各工程のゲート、アジャイルでは各反復の完了条件へ組み込む。どちらでも後付けにしない。

  198. Κάρτα 198

    Ερώτηση

    STRIDEの6分類は?

    Απάντηση

    Spoofing、Tampering、Repudiation、Information Disclosure、Denial of Service、Elevation of Privilege。脅威を体系的に考えるための観点である。

  199. Κάρτα 199

    Ερώτηση

    SASTは何を、いつ調べる?

    Απάντηση

    実行せずにソースコードや中間表現を解析する。開発早期に使いやすいが、実行時の構成や挙動は別手段で補う。

  200. Κάρτα 200

    Ερώτηση

    APIでオブジェクトIDを変えるだけで他人のデータへアクセスできる欠陥は?

    Απάντηση

    BOLA(Broken Object Level Authorization)。各要求で、主体がそのオブジェクトを操作できるか検証する。

  201. Κάρτα 201

    Ερώτηση

    APIゲートウェイへ集約しやすい横断制御は?

    Απάντηση

    認証、認可、レート制限、入力制約、ルーティング、ログ。業務オブジェクト単位の認可はアプリ側でも必要になる。

  202. Κάρτα 202

    Ερώτηση

    IdPの役割は?

    Απάντηση

    主体を認証し、信頼先が検証できるIDアサーションを発行すること。サービス提供側は署名、発行者、対象、有効期限を検証する。

  203. Κάρτα 203

    Ερώτηση

    OWASP Top 10とASVSの使い分けは?

    Απάντηση

    Top 10は代表的リスクへの意識向上、ASVSは検証可能なセキュリティ要件と評価範囲の基準に向く。

  204. Κάρτα 204

    Ερώτηση

    shift leftの本来の狙いは?

    Απάντηση

    要件・設計・実装の早い段階でセキュリティ判断と検証を行うこと。本番監視をなくす意味ではない。

  205. Κάρτα 205

    Ερώτηση

    CCSP 2026要綱でDREADの5要素は?

    Απάντηση

    Disaster(災害)、Reproducibility、Exploitability、Affected Users、Discoverability。これはCCSP 2026要綱の表記。従来のDREADは先頭をDamage(損害)とするため、資料の文脈で区別する。

  206. Κάρτα 206

    Ερώτηση

    DASTは何を、いつ調べる?

    Απάντηση

    稼働中のアプリケーションを外部から操作して挙動を調べる。実行環境の問題を見つけやすいが、コード位置の特定は苦手である。

  207. Κάρτα 207

    Ερώτηση

    ソフトウェア供給元の評価で見るべき要素は?

    Απάντηση

    開発・保守プロセス、脆弱性対応、署名と出所、依存関係、インシデント履歴、契約上の責任。継続的に再評価する。

  208. Κάρτα 208

    Ερώτηση

    安全なソフトウェア開発の実務を共有・普及する非営利の業界団体は?

    Απάντηση

    SAFECode(Software Assurance Forum for Excellence in Code)。組織的なソフトウェアセキュリティプログラムや開発実務の資料を公開している。

  209. Κάρτα 209

    Ερώτηση

    DAMが監視する対象は?

    Απάντηση

    データベースへの活動。特権操作、異常なクエリ、ポリシー違反を可視化するが、DB自体の認可設計も必要である。

  210. Κάρτα 210

    Ερώτηση

    SSOの利点と単一障害リスクは?

    Απάντηση

    認証を集約して利用者体験と統制をそろえられる一方、IdP侵害や停止の影響が広い。MFA、冗長化、強い監視で補う。

  211. Κάρτα 211

    Ερώτηση

    OWASP API Security Top 10を教育で使う目的は?

    Απάντηση

    API固有の代表的な失敗を共通語彙で認識すること。個別APIの脅威モデルと検証要件は別に作る。

  212. Κάρτα 212

    Ερώτηση

    Continuous DeliveryとContinuous Deploymentの違いは?

    Απάντηση

    Deliveryは本番投入可能な状態まで自動化し、Deploymentは合格した変更の本番投入まで自動化する。承認方式を混同しない。

  213. Κάρτα 213

    Ερώτηση

    PASTAの特徴は?

    Απάντηση

    事業影響から始め、攻撃のシミュレーションまで段階的に結ぶリスク中心の脅威モデリング手法。脅威を優先順位付きの対策へつなげる。

  214. Κάρτα 214

    Ερώτηση

    IASTはSASTやDASTと何が違う?

    Απάντηση

    テスト実行中にアプリ内部を計測し、入力とコード上の挙動を関連付ける。計測可能なテスト環境が必要になる。

  215. Κάρτα 215

    Ερώτηση

    配布アーティファクトの真正性と完全性をまとめて確認する方法は?

    Απάντηση

    信頼した鍵によるデジタル署名の検証。ハッシュは同一性を確認できるが、信頼できる署名がなければ発行者までは証明しない。

  216. Κάρτα 216

    Ερώτηση

    XMLファイアウォールが主に防ぐ対象は?

    Απάντηση

    XMLメッセージの構造・スキーマ・サイズ・内容を悪用する攻撃。DTDや外部実体、過大な構造などをポリシーで制限する。

  217. Κάρτα 217

    Ερώτηση

    MFAが強めるものと、強めないものは?

    Απάντηση

    認証の確度を強めるが、認可の設計ミスは直さない。ログイン後の過剰権限には別の制御が必要である。

  218. Κάρτα 218

    Ερώτηση

    LLMアプリ向けTop 10を教育へ含める狙いは?

    Απάντηση

    プロンプト注入、機密情報漏えい、過剰な自律権限など、生成AI固有の代表的リスクを認識すること。通常のアプリ制御も併用する。

  219. Κάρτα 219

    Ερώτηση

    安全なSDLCでリリース後も続ける活動は?

    Απάντηση

    脆弱性の受付、評価、修正、配布、利用者通知、原因分析。保守終了時の移行や廃止も計画する。

  220. Κάρτα 220

    Ερώτηση

    ATASMで順に結び付ける4要素は?

    Απάντηση

    Architecture、Threats、Attack Surfaces、Mitigations。構成を理解し、脅威が触れる面を特定して対策へつなげる。

  221. Κάρτα 221

    Ερώτηση

    正常な複数ターゲットへ要求を振り分けるクラウド部品は?

    Απάντηση

    ロードバランサー。ヘルスチェックと分散で可用性・耐障害性を高め、構成によってはTLS終端も集約できる。

  222. Κάρτα 222

    Ερώτηση

    SCAが主に可視化するものは?

    Απάντηση

    利用している第三者・オープンソース部品、その版、依存関係、既知脆弱性、ライセンス。自作コードのロジック欠陥は別の検査で補う。

  223. Κάρτα 223

    Ερώτηση

    アプリケーション層の暗号化で別途設計すべきものは?

    Απάντηση

    鍵の生成、保管、配布、ローテーション、失効、復旧、職務分離。暗号方式だけ選んでも鍵管理が弱ければ保護できない。

  224. Κάρτα 224

    Ερώτηση

    CASBの役割は?

    Απάντηση

    クラウド利用者とクラウドサービスの間で可視化とポリシー適用を支援すること。利用形態に応じてアクセス、データ、脅威、コンプライアンスを制御する。

  225. Κάρτα 225

    Ερώτηση

    インジェクション脆弱性の根本原因は?

    Απάντηση

    信頼できない入力を命令やクエリの一部として解釈させること。データと命令を分離し、入力を文脈に合わせて扱う。

  226. Κάρτα 226

    Ερώτηση

    DevSecOpsでセキュリティをパイプラインへ組み込む意味は?

    Απάντηση

    ビルド、テスト、パッケージ、配布の各段階で自動検査と証跡を作り、失敗時に停止できること。担当者の責任は自動化後も残る。

  227. Κάρτα 227

    Ερώτηση

    SBOMの主な価値は?

    Απάντηση

    ソフトウェアを構成する部品と関係を追跡できること。新しい脆弱性が公表された際の影響確認を速めるが、安全性そのものを保証しない。

  228. Κάρτα 228

    Ερώτηση

    人とワークロードで資格情報の設計を分ける理由は?

    Απάντηση

    ライフサイクル、利用速度、保管場所、失効方法が異なるため。ワークロードには自動発行できる短命なIDを優先する。

  229. Κάρτα 229

    Ερώτηση

    ブラックボックステストとホワイトボックステストの違いは?

    Απάντηση

    ブラックボックスは内部情報なし、ホワイトボックスはコードや設計情報ありで評価する。グレーボックスは一部情報を使う。

  230. Κάρτα 230

    Ερώτηση

    第三者部品の導入時にライセンスとEOLを確認する理由は?

    Απάντηση

    利用・配布条件への違反と、保守終了後に修正を受けられないリスクを避けるため。代替や更新の計画も持つ。

  231. Κάρτα 231

    Ερώτηση

    サンドボックスの目的は?

    Απάντηση

    信頼できないコードや処理を制限された環境で動かし、ホストや他資源への影響を抑えること。境界自体の脆弱性も監視する。

  232. Κάρτα 232

    Ερώτηση

    アプリの秘密情報をソースコードへ埋め込まない代替策は?

    Απάντηση

    専用のシークレット管理基盤から、実行時に必要な主体だけへ短期間提供する。保管、転送、ローテーション、監査を集中管理する。

  233. Κάρτα 233

    Ερώτηση

    データの保存・処理場所によって適用法や政府アクセス条件が変わるリスクは?

    Απάντηση

    法律・管轄権の問題。データ所在地、越境移転、規制、契約、開示要求を展開前に確認し、許容するリージョンと処理経路を定める。

  234. Κάρτα 234

    Ερώτηση

    ASVSを調達や受入れで使う利点は?

    Απάντηση

    要求する検証項目と厳格さを、契約と受入基準へ具体的に記述できること。曖昧な「安全であること」を検証可能にする。

  235. Κάρτα 235

    Ερώτηση

    IaCのセキュリティレビューを本番前に行う価値は?

    Απάντηση

    公開設定、過剰権限、暗号化漏れなどを再現可能な構成定義上で検出できること。手動変更によるずれも抑える。

  236. Κάρτα 236

    Ερώτηση

    入力検証と出力エンコーディングの役割の違いは?

    Απάντηση

    入力検証は受け入れる値を制約し、出力エンコーディングは表示先の文脈で値が命令として解釈されるのを防ぐ。両方を使い分ける。

  237. Κάρτα 237

    Ερώτηση

    abuse caseテストが通常のユースケーステストへ加える視点は?

    Απάντηση

    攻撃者や誤用者が機能をどう悪用し、制御を回避するかという視点。想定した防御が失敗する経路を試す。

  238. Κάρτα 238

    Ερώτηση

    依存パッケージの版固定と来歴証明を併用する理由は?

    Απάντηση

    版固定で再現性を保ち、来歴で誰がどの工程から生成したか確認するため。信頼できる更新判断には両方が役立つ。

  239. Κάρτα 239

    Ερώτηση

    マイクロサービスで信頼境界として重点確認すべき場所は?

    Απάντηση

    信頼の前提やレベルが変わるインターフェース。典型例はサービス間や外部サービスとの通信境界である。サービスIDは主体、ネットワーク経路はデータフロー、データストアは構成要素・資産であり、それ自体が常に信頼境界とは限らない。

  240. Κάρτα 240

    Ερώτηση

    SQLインジェクションを防ぐ第一選択は?

    Απάντηση

    パラメーター化クエリ/プリペアドステートメント。入力値をSQL命令から分離し、必要に応じて許可リスト検証も行う。

  241. Κάρτα 241

    Ερώτηση

    一般教育に加えて開発者へ演習させるべき内容は?

    Απάντηση

    実際の技術スタックでの安全な実装、脆弱な例の修正、ツール結果の判断。知識確認だけでなく行動へ結び付ける。

  242. Κάρτα 242

    Ερώτηση

    TLS証明書の期限切れや管理漏れを防ぐため、一貫して管理するライフサイクルは?

    Απάντηση

    証明書の発見・棚卸し、所有者設定、発行・配備、監視、更新、失効、撤去。自動化と監査で無管理証明書や期限切れを減らす。

  243. Κάρτα 243

    Ερώτηση

    ソフトウェア構成管理とバージョン管理が守るものは?

    Απάντηση

    承認済み構成の再現性、変更の追跡性、完全性。コードだけでなく依存関係、設定、IaC、パイプライン定義も対象にする。

  244. Κάρτα 244

    Ερώτηση

    CI/CDのセキュリティゲートで停止条件にすべきものは?

    Απάντηση

    組織のリスク基準を超える未解決の問題。重大脆弱性、署名失敗、秘密漏えい、ポリシー違反などを明示し、例外を記録する。

  245. Κάρτα 245

    Ερώτηση

    APIのレート制限が主に抑えるリスクは?

    Απάντηση

    資源枯渇、総当たり、スクレイピング、予期しない費用増加。主体、操作、資源コストに応じて制限し、認可の代替にはしない。

  246. Κάρτα 246

    Ερώτηση

    サービスメッシュで統一しやすいサービス間制御は?

    Απάντηση

    相互認証、暗号化、認可ポリシー、通信観測、再試行、遮断。アプリコード外で一貫して適用できるが、業務認可は別途必要である。

  247. Κάρτα 247

    Ερώτηση

    SANS Top 25(現在のCWE Top 25)が示すものは?

    Απάντηση

    重大かつ頻出するソフトウェア弱点の一覧。代表的な弱点への意識向上と教育に使い、個別アプリの脅威モデルや検証要件は別に定める。

  248. Κάρτα 248

    Ερώτηση

    QA(Quality Assurance)の中心目的は?

    Απάντηση

    開発プロセスと成果物が定めた品質・セキュリティ基準を満たすという保証を得ること。個別テストの実行だけでなく、基準、レビュー、欠陥管理、改善も含む。

  249. Κάρτα 249

    Ερώτηση

    CSP内部者の脅威や可視性・制御の喪失をまとめて評価するのは、どのリスク群か?

    Απάντηση

    クラウド固有のアプリケーションリスク。基盤の特権操作と一部の監視・制御をCSPへ委ねるため、責任共有境界、監査可能性、契約上の対応も確認する。

  250. Κάρτα 250

    Ερώτηση

    DockerとKubernetesを役割で見分けると?

    Απάντηση

    Dockerはコンテナイメージの構築とコンテナ実行、Kubernetesは複数コンテナの配置・拡縮・更新などのオーケストレーションに使われる。

  251. Κάρτα 251

    Ερώτηση

    HSMとTPMは、鍵の保護対象がどう違う?

    Απάντηση

    HSMは暗号鍵を保護・管理して暗号処理を行う物理装置、TPMはコンピューターに組み込まれ、少量の鍵などを保護する耐タンパー集積回路です。

  252. Κάρτα 252

    Ερώτηση

    管理ポートをインターネットへ直接公開せず、特権アクセスを一か所で監視する構成は?

    Απάντηση

    踏み台ホスト(bastion host/jumpbox)です。MFA、時間制限、操作記録を組み合わせます。

  253. Κάρτα 253

    Ερώτηση

    変更管理と構成管理の最短の違いは?

    Απάντηση

    変更管理は変更の提案・評価・承認を統制し、構成管理は承認済みの構成項目と状態を維持します。

  254. Κάρτα 254

    Ερώτηση

    クラウドのデジタルフォレンジックで、最初に可用性を確認すべき証拠は?

    Απάντηση

    揮発性の高い証拠です。RAMや稼働中VM内のログなど、停止・解放で失われ得るものから取得可能性を確認します。

  255. Κάρτα 255

    Ερώτηση

    インシデント連絡計画で事前に決めるべき要素は?

    Απάντηση

    担当者、承認者、連絡先、対象者、手段、タイミングです。未確認事項を断定しないルールも含めます。

  256. Κάρτα 256

    Ερώτηση

    SOCの中心的な役割は?

    Απάντηση

    セキュリティ事象を継続監視し、検知、トリアージ、エスカレーション、対応調整を行うことです。

  257. Κάρτα 257

    Ερώτηση

    secure by defaultとは、導入直後の状態をどうする考え方?

    Απάντηση

    重要な保護機能を初期状態から有効にし、危険な既定値や不要な公開を避ける考え方です。

  258. Κάρτα 258

    Ερώτηση

    クラウド管理でRDPやSSHを使うときの基本方針は?

    Απάντηση

    公開範囲を絞り、踏み台や管理サービス経由でMFAと短時間の権限を使い、接続を記録します。

  259. Κάρτα 259

    Ερώτηση

    安全な変更記録に最低限必要な内容は?

    Απάντηση

    目的、影響、リスク、承認、実施手順、検証方法、ロールバック条件、実施結果です。

  260. Κάρτα 260

    Ερώτηση

    証拠取得の順序を決める基準は?

    Απάντηση

    揮発性と消失リスクです。法務・安全上許される範囲で、変化しやすい実行状態を永続ディスクやバックアップより先に扱います。

  261. Κάρτα 261

    Ερώτηση

    CSPとのインシデント対応で、契約と手順に定めることは?

    Απάντηση

    契約では責任分担、情報の流れ、連携方法、CSPの行動権限を定めます。手順では優先度付け、通知先と時期、影響資産の確認、証拠の保持を扱います。

  262. Κάρτα 262

    Ερώτηση

    AIをセキュリティ監視に使う場合、人による検証が残る理由は?

    Απάντηση

    AIの出力を運用環境の文脈で解釈し、妥当性と信頼性を継続評価する必要があるためです。基準値と専門家の判断で検証します。

  263. Κάρτα 263

    Ερώτηση

    クラウド管理プレーンの特権操作に優先する統制は?

    Απάντηση

    最小権限、MFA、職務分離、緊急用アカウント、改ざんに強い監査ログです。

  264. Κάρτα 264

    Ερώτηση

    SSOを管理アクセスへ導入する主な運用上の利点と注意点は?

    Απάντηση

    利点は認証と退職・異動処理の集中化です。IdPが高影響な依存先になるため、MFA、冗長化、緊急アクセスも必要です。

  265. Κάρτα 265

    Ερώτηση

    継続性管理が対象にするものは?

    Απάντηση

    中断時にも重要業務を許容水準で続け、復旧するための人、手順、技術、代替手段です。

  266. Κάρτα 266

    Ερώτηση

    仮想ディスクのスナップショットだけでは、フォレンジック証拠が不足する理由は?

    Απάντηση

    クラウドの証拠はVM外のログや管理APIなどにも分散し、仮想ディスクだけでは全体を取得できないためです。

  267. Κάρτα 267

    Ερώτηση

    顧客向けインシデント通知の手順で事前に定めることは?

    Απάντηση

    通知内容、通知先、通知時期です。初報後も定期更新し、影響を受けた顧客へ、適用される法令・規制に従って通知します。

  268. Κάρτα 268

    Ερώτηση

    SIEMとログ管理の違いは?

    Απάντηση

    ログ管理は収集・保管・検索を支え、SIEMは複数ソースを相関して検知やアラートにつなげます。

  269. Κάρτα 269

    Ερώτηση

    管理プレーン用ツールを導入するときの安全な配置は?

    Απάντηση

    業務トラフィックから分離した管理経路に置き、強固な認証、暗号化、最小権限、操作ログを適用します。

  270. Κάρτα 270

    Ερώτηση

    VLANだけを強いセキュリティ境界とみなせない理由は?

    Απάντηση

    VLANは主にレイヤー2の論理分割だからです。通信制御にはファイアウォール、ルーティング制御、認証なども使います。

  271. Κάρτα 271

    Ερώτηση

    ISMSは単独のセキュリティ製品ではなく何?

    Απάντηση

    情報セキュリティの方針、リスク、統制、評価、改善を継続的に管理する仕組みです。

  272. Κάρτα 272

    Ερώτηση

    取得した証拠のハッシュ値が示せることと、示せないことは?

    Απάντηση

    取得後に内容が変わっていないことの検証に使えます。誰が作成した証拠かを、ハッシュだけで証明することはできません。

  273. Κάρτα 273

    Ερώτηση

    規制当局へのインシデント連絡を判断する軸は?

    Απάντηση

    適用法、管轄、通知条件、期限、必要項目です。法務・プライバシー担当と確認し、判断過程も記録します。

  274. Κάρτα 274

    Ερώτηση

    脅威インテリジェンスをそのまま検知ルールにしない理由は?

    Απάντηση

    古い指標や自組織に無関係な情報が混ざるためです。信頼性、鮮度、環境との関連性を評価します。

  275. Κάρτα 275

    Ερώτηση

    仮想化基盤でハイパーバイザーが担う主要なセキュリティ機能は?

    Απάντηση

    VM間の分離を保ち、CPU、メモリ、ネットワーク、ストレージへのアクセスを仲介することです。

  276. Κάρτα 276

    Ερώτηση

    TLSが主に保護する対象は?

    Απάντηση

    通信中のデータです。機密性と完全性、通常はサーバー認証を提供しますが、保存データは別の統制が必要です。

  277. Κάρτα 277

    Ερώτηση

    継続的サービス改善で、改善候補をどう選ぶ?

    Απάντηση

    測定結果を目標や基準値と比べ、改善機会に優先順位を付けます。実施後は効果を測り直します。

  278. Κάρτα 278

    Ερώτηση

    chain of custodyに記録するものは?

    Απάντηση

    証拠を誰が、いつ、どこで、なぜ取得・移送・保管・分析したかと、各時点の完全性情報です。

  279. Κάρτα 279

    Ερώτηση

    パートナーへインシデント情報を共有するときの原則は?

    Απάντηση

    合意済みの手順に従い、対応に必要な範囲だけを、承認された安全な経路で共有します。

  280. Κάρτα 280

    Ερώτηση

    インシデント対応を一回限りの封じ込めで終えないための流れは?

    Απάντηση

    準備と検知を土台に、対応で封じ込め・排除し、復旧後に学びを統制へ戻します。

  281. Κάρτα 281

    Ερώτηση

    Type 1とType 2ハイパーバイザーの配置の違いは?

    Απάντηση

    Type 1は物理ハードウェア上で直接動作し、Type 2はホストOS上で動作します。分類だけで安全性は決まりません。

  282. Κάρτα 282

    Ερώτηση

    DNSSECがDNSへ追加する保護は?

    Απάντηση

    DNS応答の出所認証と完全性検証です。問い合わせ内容を暗号化する仕組みではありません。

  283. Κάρτα 283

    Ερώτηση

    インシデント管理と問題管理の違いは?

    Απάντηση

    インシデント管理はサービスの早期復旧を優先し、問題管理は根本原因と再発防止を扱います。

  284. Κάρτα 284

    Ερώτηση

    legal holdが通常の保持・削除手順へ与える影響は?

    Απάντηση

    対象となる電子情報の削除や上書きを停止します。対象、期間、保管担当を明確にします。

  285. Κάρτα 285

    Ερώτηση

    脆弱性評価とペネトレーションテストの違いは?

    Απάντηση

    脆弱性評価は弱点を広く発見・優先付けし、ペネトレーションテストは許可された範囲で悪用可能性や影響を実証します。

  286. Κάρτα 286

    Ερώτηση

    ゲストOSのguest toolsで、不要な共有機能を無効にする理由は?

    Απάντηση

    ホストや別VMとのファイル・クリップボード共有などが、マルウェアや不正アクセスの経路になり得るためです。必要な連携だけを残します。

  287. Κάρτα 287

    Ερώτηση

    VPNを使えば接続元を自動的に信頼できる?

    Απάντηση

    できません。VPNは主にトンネルを保護します。利用者・端末の認証、認可、状態確認は別途必要です。

  288. Κάρτα 288

    Ερώτηση

    リリース管理とデプロイ管理の違いは?

    Απάντηση

    リリース管理は承認済み変更を利用可能にする単位と計画を扱い、デプロイ管理は構成要素を対象環境へ移します。

  289. Κάρτα 289

    Ερώτηση

    複数クラウドの証拠を時系列で突き合わせる前提は?

    Απάντηση

    信頼できる時刻同期とタイムゾーンの正規化です。元の時刻表記と補正方法も残します。

  290. Κάρτα 290

    Ερώτηση

    AIサービスのmodel driftをセキュリティ運用でどう扱う?

    Απάντηση

    期待した基準からの逸脱を調査すべきシグナルとして扱います。ドリフトだけで攻撃と断定しません。

  291. Κάρτα 291

    Ερώτηση

    IaCが安全な構成ベースラインの維持に役立つ理由は?

    Απάντηση

    構成を版管理・レビューし、承認済みの既知状態を再現できるためです。ドリフト検知と組み合わせます。

  292. Κάρτα 292

    Ερώτηση

    IDSとIPSの運用上の違いは?

    Απάντηση

    IDSは検知して通知し、IPSは通信経路上で遮断も行います。IPSは誤検知による可用性影響も評価します。

  293. Κάρτα 293

    Ερώτηση

    CMDBで維持する情報は?

    Απάντηση

    サービスを支える構成項目(CI)の構成と、その関係です。必要なときに正確で信頼できる情報を使える状態にします。

  294. Κάρτα 294

    Ερώτηση

    マルチテナント環境で顧客が直接取得できない証拠は、どう確保する?

    Απάντηση

    CSPのフォレンジック手順、ログ提供範囲、保存期間、応答時間を契約と対応手順に組み込みます。

  295. Κάρτα 295

    Ερώτηση

    可用性管理と継続性管理の焦点の違いは?

    Απάντηση

    可用性管理は平常時を含むサービス可用性の達成を扱い、継続性管理は重大な中断後の業務継続と復旧を扱います。

  296. Κάρτα 296

    Ερώτηση

    容量管理で需要予測と同時に確認するものは?

    Απάντηση

    現在の資源使用量、サービス性能、コストです。履歴から将来の容量需要を予測し、業務需要を満たすよう資源を最適化します。

  297. Κάρτα 297

    Ερώτηση

    honeypotの主な目的は?

    Απάντηση

    攻撃者を本番資産から隔離したおとりへ誘導し、挙動を観測することです。本番データは置きません。

  298. Κάρτα 298

    Ερώτηση

    クラウドのNetwork Security Group(NSG)は何をする?

    Απάντηση

    ワークロードや仮想インターフェース周辺で、送受信をルールに基づいて許可・拒否する論理的な通信制御です。

  299. Κάρτα 299

    Ερώτηση

    クラスタのHAだけではDRにならない理由は?

    Απάντηση

    同じ障害領域や誤操作の影響を共有し得るためです。独立した復旧先、データ復旧、手順、試験が別途必要です。

  300. Κάρτα 300

    Ερώτηση

    サービスレベル管理の役割は?

    Απάντηση

    事業要件を測定可能なSLAへ落とし込み、実績を監視し、逸脱時の対応と改善を管理することです。

  301. Κάρτα 301

    Ερώτηση

    性能・容量監視で単一時点のCPU使用率だけでは不十分な理由は?

    Απάντηση

    資源使用量とサービス性能の履歴・関係を見ないと、弱点や将来の容量需要を特定できないためです。

  302. Κάρτα 302

    Ερώτηση

    OSハードニングの基準になるものは?

    Απάντηση

    承認済みのセキュア構成ベースラインです。不要サービスを止め、権限と設定を絞り、継続監視で逸脱を修正します。

  303. Κάρτα 303

    Ερώτηση

    ホストが高可用でも、ゲストOSの可用性を別に設計する理由は?

    Απάντηση

    ゲストOSやアプリだけが停止する障害があるためです。ヘルスチェック、再起動、複数インスタンスを設計します。

  304. Κάρτα 304

    Ερώτηση

    NIST、ISO、CIS Controls、COBIT、ITILを一つのチェックリストとして扱わない理由は?

    Απάντηση

    目的と抽象度が違うためです。NIST CSFはサイバーリスク管理の成果、ISO/IEC 27001はISMS要件、CIS Controlsは優先度付きの防御策、COBITは企業I&Tのガバナンスと管理、ITILはサービス管理を扱います。

  305. Κάρτα 305

    Ερώτηση

    リスクベースのパッチ管理の基本サイクルは?

    Απάντηση

    対象を把握し、優先度を決め、取得・検証・展開し、適用結果を確認します。例外と期限も追跡します。

  306. Κάρτα 306

    Ερώτηση

    物理ホスト監視で容量指標とは別に追うべき健康指標は?

    Απάντηση

    ディスク障害、温度、ファン、電源、メモリエラーなどです。しきい値超過を交換や退避につなげます。

  307. Κάρτα 307

    Ερώτηση

    オーケストレーターの操作に強い統制が必要な理由は?

    Απάντηση

    一つの操作が多数の資源へ波及するためです。RBAC、policy as code、承認、監査ログで爆発半径を抑えます。

  308. Κάρτα 308

    Ερώτηση

    バックアップの存在ではなく、復旧可能性を確認する方法は?

    Απάντηση

    定期的なリストア試験です。データだけでなく、構成、鍵、依存サービス、手順、所要時間も確認します。

  309. Κάρτα 309

    Ερώτηση

    クラウドデータの保存場所が法務判断に直結する理由は?

    Απάντηση

    データの保存・処理場所によって、適用される法令や域外移転の制約が変わり得るためです。CSPが複数法域へ複製する可能性も確認します。

  310. Κάρτα 310

    Ερώτηση

    契約上の機密データと法令で規制される個人データの違いは?

    Απάντηση

    前者の義務は主に契約から、後者の義務は適用法から生じます。同じデータが両方に該当することもあります。

  311. Κάρτα 311

    Ερώτηση

    内部監査と外部監査の違いは?

    Απάντηση

    内部監査は組織自身またはその代理が行う第一者監査です。外部監査は組織外の者が行い、顧客などによる第二者監査と、独立機関による第三者監査を含みます。

  312. Κάρτα 312

    Ερώτηση

    CSPのリスク管理プログラムを評価するときに見るものは?

    Απάντηση

    統制、評価方法、方針、リスクプロファイル、リスク選好、例外処理と、それらが動いている証拠です。

  313. Κάρτα 313

    Ερώτηση

    SLA、MSA、SOWの役割の違いは?

    Απάντηση

    SLAは測定するサービス水準、MSAは複数の個別発注に共通する契約条件、SOWは個別作業の範囲・成果物・日程を定めます。

  314. Κάρτα 314

    Ερώτηση

    複数国の法令要求が衝突したときの最初の対応は?

    Απάντηση

    対象データ、処理、国、当事者を特定し、法務担当と要求を比較します。技術部門だけで優先法を決めません。

  315. Κάρτα 315

    Ερώτηση

    組織全体・機能別・クラウド向けのセキュリティ方針は、監査でどう区別する?

    Απάντηση

    組織方針は全社の原則と権限、機能別方針はアクセス管理など特定領域の要求、クラウド方針はクラウド利用条件と責任分担を定めます。監査では上位方針から手順と実装証拠まで整合をたどります。

  316. Κάρτα 316

    Ερώτηση

    目的制限とデータ最小化の違いは?

    Απάντηση

    目的制限は定めた目的の範囲で処理する原則、データ最小化はその目的に必要な量だけ扱う原則です。

  317. Κάρτα 317

    Ερώτηση

    クラウド監査で、CSPのセキュリティ主張を支える第三者保証をどう扱う?

    Απάντηση

    認証やコンプライアンスレビューをそのまま受け入れず、可能なら組織による独立評価で検証します。保証が自組織の具体的なクラウド環境まで及ぶかも確認します。

  318. Κάρτα 318

    Ερώτηση

    リスク選好、リスク許容度、リスクプロファイルの違いは?

    Απάντηση

    選好は価値の追求で受け入れるリスクの種類と量、許容度は受け入れ可能な具体的水準、プロファイルは評価で特定した重要リスクの優先一覧です。CSFのCurrent/Target Organizational Profileとは別です。

  319. Κάρτα 319

    Ερώτηση

    ベンダーロックインを契約前に下げる要件は?

    Απάντηση

    データ形式、エクスポート方法、API、移行支援、削除証明、費用、終了期限を出口計画として定めます。

  320. Κάρτα 320

    Ερώτηση

    契約の準拠法条項だけで、法令上の義務をなくせる?

    Απάντηση

    なくせません。契約で準拠法や紛争地を定めても、強行法規やデータ主体に関する適用法は別に評価します。

  321. Κάρτα 321

    Ερώτηση

    ISO/IEC 27018:2025が主に対象とするクラウド上の役割は?

    Απάντηση

    PIIプロセッサとして動くパブリッククラウド事業者です。クラウド向けのPII保護ガイダンスを示します。

  322. Κάρτα 322

    Ερώτηση

    外部委託リスクの評価で、SOC保証報告は何に役立つ?

    Απάντηση

    サービス組織のシステムレベル統制に関する情報を提供し、利用者が外部委託サービスのリスクを評価・対応する助けになります。

  323. Κάρτα 323

    Ερώτηση

    インドDPDP Actで、施行後にインド拠点DPOと独立データ監査人の選任義務を負う指定対象は?

    Απάντηση

    Significant Data Fiduciaryです。中央政府が処理量・機微性やData Principalの権利へのリスクなどを踏まえて指定します。ただしsection 10は、2025年11月13日の官報掲載から18か月後に施行されるため、2026年8月27日時点では未施行です(換算日: 2027年5月13日)。

  324. Κάρτα 324

    Ερώτηση

    クラウド契約で継続的な保証を確保する条項は?

    Απάντηση

    監査権、証拠提供、セキュリティ要件、違反通知、下請管理、データアクセス・所有、終了時返却・削除です。

  325. Κάρτα 325

    Ερώτηση

    eDiscoveryの代表的な流れは?

    Απάντηση

    関連するESIを特定し、保全、収集、処理、レビュー、分析し、必要な形式で提出します。

  326. Κάρτα 326

    Ερώτηση

    DPIAを処理開始前に行う典型条件は?

    Απάντηση

    個人の権利と自由に高いリスクを生じる可能性が高い処理です。必要性、比例性、リスク、軽減策を評価します。

  327. Κάρτα 327

    Ερώτηση

    SSAEとISAE 3000の発行主体と対象の違いは?

    Απάντηση

    SSAEはAICPA Auditing Standards Boardが公表するattestation standardsです。ISAE 3000はIAASBが公表し、過去財務情報の監査・レビュー以外のassurance engagementsを対象にします。

  328. Κάρτα 328

    Ερώτηση

    GDPRの個人データ侵害で、説明責任のために記録する内容は?

    Απάντηση

    侵害の事実、影響、講じた是正措置です。監督機関への通知要否と、その判断理由も記録します。

  329. Κάρτα 329

    Ερώτηση

    重要ベンダーの中断リスクに備える基本策は?

    Απάντηση

    ベンダーとサービスのリスク変化を継続監視し、予期しない供給中断に備えた継続計画と役割を事前に定めます。

  330. Κάρτα 330

    Ερώτηση

    legal holdを開始したら、クラウドの自動削除へ何をする?

    Απάντηση

    対象アカウント、期間、データ種別を特定し、ライフサイクル削除やログローテーションを停止・例外化します。

  331. Κάρτα 331

    Ερώτηση

    GDPR域外移転で確認する代表的な移転根拠は?

    Απάντηση

    十分性認定、またはSCCなどの適切な保護措置です。移転先法制と追加措置の必要性も評価します。

  332. Κάρτα 332

    Ερώτηση

    SOC 1、SOC 2、SOC 3の使い分けは?

    Απάντηση

    SOC 1は利用組織の財務報告に係る内部統制を扱います。SOC 2とSOC 3はsecurity、availability、processing integrity、confidentiality、privacyに関する統制を扱い、SOC 3はSOC 2より詳細が少ない一般利用向け報告です。

  333. Κάρτα 333

    Ερώτηση

    リスク対応のavoid、mitigate、transfer、share、acceptとは?

    Απάντηση

    回避、低減、移転、分担、受容です。移転や分担を選んでも、組織の説明責任まで消えるわけではありません。

  334. Κάρτα 334

    Ερώτηση

    クラウドのサプライチェーンリスク評価を一次CSPで止めない理由は?

    Απάντηση

    下請事業者、ソフトウェア、運用委託先にも依存するためです。重要な依存関係と変更通知を契約・監視対象にします。

  335. Κάρτα 335

    Ερώτηση

    eDiscoveryでdefensible collectionといえる取得方法は?

    Απάντηση

    対象と手順が説明でき、再現可能で、取得ログ、完全性検証、chain of custodyが残る方法です。

  336. Κάρτα 336

    Ερώτηση

    GDPRの個人データ侵害で、72時間以内の監督機関通知が原則不要なのは?

    Απάντηση

    個人の権利と自由にリスクを生じる可能性が低い場合です。それ以外は、認識後、不当な遅延なく、可能なら72時間以内に通知します。

  337. Κάρτα 337

    Ερώτηση

    ギャップ分析で比較する二つの状態は?

    Απάντηση

    現在の統制状態と、法令・契約・基準・リスクから定めた目標状態です。差分を是正計画へつなげます。

  338. Κάρτα 338

    Ερώτηση

    複数のリスクフレームワークを使うとき、名称合わせより重要なことは?

    Απάντηση

    目的、範囲、評価尺度、責任者、証拠を対応付けることです。クロスウォークは未対応や重複の把握に使います。

  339. Κάρτα 339

    Ερώτηση

    ISO/IEC 27050-1が整理する分野は?

    Απάντηση

    電子的に保存された情報(ESI)のeDiscoveryです。特定、保全、収集、処理、レビュー、分析、提出などの概念を扱います。

  340. Κάρτα 340

    Ερώτηση

    HIPAAのPHIとは?

    Απάντηση

    対象事業者またはbusiness associateが保持・送信する、個人を識別できる健康情報です。すべての健康データが自動的にPHIになるわけではありません。

  341. Κάρτα 341

    Ερώτηση

    クラウドの統制評価計画に必要な基本要素は?

    Απάντηση

    評価の目的と範囲、対象統制、評価手順・方法・対象、評価の深さとカバレッジ、実施承認です。

  342. Κάρτα 342

    Ερώτηση

    KRIとKPIの違いは?

    Απάντηση

    KRIはリスクを測る指標、KPIは意図した成果への進捗を測る指標です。どちらもメトリクスですが、測る対象が違います。

  343. Κάρτα 343

    Ερώτηση

    クラウド契約にフォレンジック支援を明記するなら、何を定める?

    Απάντηση

    取得可能なログとスナップショット、保持期間、時刻同期、証拠形式、連絡窓口、応答時間、法的手続への協力です。

  344. Κάρτα 344

    Ερώτηση

    FERPAが主に保護するものは?

    Απάντηση

    米国教育省の対象プログラムから資金を受ける教育機関の教育記録です。保護者またはeligible studentに閲覧・訂正・開示統制の権利を与えます。

  345. Κάρτα 345

    Ερώτηση

    ISMSと個別の内部情報セキュリティ統制の関係は?

    Απάντηση

    ISMSは情報セキュリティリスクを管理し、継続的に改善する体系です。個別統制はアクセス制御やログなどの具体的な対策です。

  346. Κάρτα 346

    Ερώτηση

    クラウドのリスク環境を四つの層で見るなら?

    Απάντηση

    サービス、ベンダー、インフラストラクチャ、事業です。各層の依存関係と単一障害点も評価します。

  347. Κάρτα 347

    Ερώτηση

    証拠のハッシュ一致だけでは法的採用可能性を保証できない理由は?

    Απάντηση

    関連性、真正性、取得の適法性、保管手順、管轄の証拠規則も問われるためです。

  348. Κάρτα 348

    Ερώτηση

    PIPEDAの10原則が扱う中心テーマは?

    Απάντηση

    民間組織による個人情報の収集・利用・開示と本人アクセスです。説明責任、目的、同意、最小化、安全管理などを含みます。

  349. Κάρτα 349

    Ερώτηση

    クラウド監査の計画段階で巻き込むべき関係者は?

    Απάντηση

    業務・統制責任者、セキュリティ、法務、プライバシー、運用、調達、CSP、監査人です。証拠の所有者も特定します。

  350. Κάρτα 350

    Ερώτηση

    controllerとprocessorの役割の違いは?

    Απάντηση

    controllerは個人データ処理の目的と手段を決め、processorはcontrollerのために、その指示に基づいて処理します。

  351. Κάρτα 351

    Ερώτηση

    NERC CIP、HIPAA/HITECH、PCI DSSの対象を区別する軸は?

    Απάντηση

    NERC CIPはBulk Electric Systemの対象組織・資産、HIPAA/HITECHは対象保健医療情報、PCI DSSは決済アカウントデータ環境です。対象範囲を個別に確認します。

  352. Κάρτα 352

    Ερώτηση

    日本の個人情報保護法で、外国の第三者へ本人同意に基づき個人データを提供する前に必要なことは?

    Απάντηση

    原則として、国名、その国の個人情報保護制度、受領者の保護措置など、判断に必要な情報を本人へ提供します。例外や同等措置の条件は最新ガイドラインで確認します。

  353. Κάρτα 353

    Ερώτηση

    分散IT環境で監査・法令漏れを防ぐ最初の台帳は?

    Απάντηση

    リージョン、データフロー、サービス、アカウント、下請事業者、適用法、統制責任、証拠所在を結ぶ台帳です。

  354. Κάρτα 354

    Ερώτηση

    監査要件でクラウドログの保持期間が延びたら、設計・運用で何を変える?

    Απάντηση

    保持期間を満たす保存容量を確保し、ログを不正アクセス・変更・削除から保護して、必要時に取得できる状態を維持します。

中央の保護されたクラウドと、周囲で連携する6つのセキュリティ領域を描いた抽象図

354 κάρτες

CCSP 2026 試験対策フラッシュカード:6ドメイン総復習

Μελετήστε αυτήν τη δέσμη δωρεάν

Το Nibomo ανοίγει για να ξεκινήσετε τη μελέτη.