月別アーカイブ: 2025年5月

CCSKv5 合格体験記

コメントをどうぞ

【CCSKv5 合格体験記】

～体系的なクラウドセキュリティ理解の第一歩として～

クラウドセキュリティに関する知識と理解を深め、実務に活かせるスキルを証明する資格として注目されているのが、CSA（Cloud Security Alliance）が提供するCCSK（Certificate of Cloud Security Knowledge）です。その最新版である「CCSK v5」は、広範なクラウドセキュリティの知識体系を網羅しており、学習から試験対策、実務への応用まで、多くの気づきと発見を与えてくれる内容となっています。

今回は、実際にこのCCSK v5に挑戦し、無事に合格を果たした筆者が、自身の学習プロセスや試験体験、そして今後への活用について、個人的な視点からまとめてみました。これから受験を考えている方や、クラウドセキュリティの学習を始めようとしている方にとって、少しでも参考になれば幸いです。

1. 試験に向けてどのように勉強したか

CCSKv5の受験に向けて、まず取り組んだのはCSAの公式資料であるCCSK v5 Prep Kitと、Certificate of Cloud Security Knowledge v5 Exam Bundleに含まれるオンラインコースの受講でした。このコースには「CCSK orb」という専用のGPTが付属しており、自然言語での質問に答えてくれるサポート機能があります。日本語にも対応しているため、理解を深める上で非常に役立ちました。

加えて、CSA JAPANが提供している日本語の資料もフル活用しました。特にSecurity Guidanceの日本語訳は、理解の補完に非常に有効であり欠かせないものでした。また、CCSK v5 Prep Kitに含まれるSecurity GuidanceとPractice ExamをChatGPTにアップロードし、セクションごとの復習問題を生成しながら学習を進めました。この方法を用いると、Practice Exam の出題方法をモデルにし、Security Guidance の内容から問題を作成してくれます。ただし、問題のレベルとは若干差異が見られました。

学習期間は約半年かかりました。2024年11月から学習を開始し、最初の2か月はオンラインコース中心に学びましたが、理解が浅く合格できる基準にないと感じたため、その後は日本語資料での読み込みを中心にじっくり進めていきました。

効果的だったのは、まず12のドメインの枠組みを頭に入れ、全体像を意識しながら学ぶことです。ドメイン間の関係性（ビジネス・技術・運用の観点）を把握することで、理解が格段に深まりました。また、Practice Examにトライすることで出題傾向やレベル感が見えてくるため、非常に有効でした。

試験範囲が広いため、丸暗記は現実的ではありません。要点を押さえる形での繰り返し学習と、アウトプット型のトレーニング（問題演習）が重要だと感じました。

2. CCSKv5の試験概要・特徴

試験は60問の選択式で、全問において4つの選択肢から1つを選ぶ形式です。合格基準が80%の正答になるため、49問以上の正答で合格になります。実試験はPractice Examに非常に近い形式で出題されました。選択肢のうち、明らかに誤っているものが2つ程度含まれていることも多く、実質的には二択問題として解けるケースも多かったです。

試験時間は120分と十分ありますが、すべてのドキュメント参照が許されるとはいえ、最初から頼ると時間が足りなくなる可能性があります。私は最初の30分で一通り回答し、残りの90分を確認フェーズとして必要な部分をガイドで確認するスタイルを取りました。

英語については、そこまで難解ではないものの、ある程度読み慣れていないと苦戦する可能性があります。私は念のため、日本語版ガイドと英語版を並べて参照しながら確認しました。

受験は完全オンライン（BYOD）で、自宅やカフェなどでも受験可能です。ただし、一度開始すると通信トラブルがあっても時計は止まらないため、受験環境（特にネットワーク）の安定性には十分注意が必要です。

3. 傾向と対策（個人的な体験談としての傾向と対策）

出題傾向について、問題を持ち帰ることができないため断定はできませんが、全ドメインからバランス良く出題されている印象でした。特定の技術や知識というよりも、CSAが提示するガイドラインやフレームワークの「本質」に相当するような箇所にフォーカスした出題が多かったと感じています。

個人的に難しいと感じたのは、ドメイン2～4のガバナンス領域でした。私は技術職のため、こうしたビジネス寄りのトピックには慣れておらず、理解に時間がかかりました。

逆に、技術職の方にとって重要だと感じたポイントは以下の通りです：

  • クラウド環境における責任共有モデルの理解
  • IaaS / PaaS / SaaSの各モデルにおけるセキュリティの考え方
  • クラウド特有の運用（アプリケーション、サーバレス、開発プロセス）
  • IAM（アイデンティティ＆アクセス管理）を中心とした認証・認可の設計

特にIAMを含むドメイン5の内容は、他の領域とも深く関係しており、重点的に学習することをおすすめします。

4. 今後の抱負・自由記述

CCSK受験のきっかけは、オーストラリア人の上司からの勧めでした。私たちの会社では主にネットワークスイッチ製品を取り扱っていますが、我々の顧客の多くはクラウドシフトしている中でもなおオンプレミス思考から脱却できずにいます。クラウドを導入する上で、セキュリティの観点から正しくアドバイスできる人材が求められており、その期待に応えるべく、受験を決めました。

私自身、これまでにAWS, Microsoft Azure, Google Cloud をはじめとした複数のクラウドベンダーのアーキテクト資格を取得してきましたが、クラウドサービス自体は異なるものの、認定試験で問われる内容は比較的内容が似通っているものの、各ベンダの独自色を出すがゆえに包括的なセキュリティ視点を養うには至りませんでした。CCSKはその空白を埋める資格として、非常に有効でした。

今後はこの資格で得た知識を活かし、クラウドセキュリティの重要性をお客様に伝え、マインドチェンジを促していきたいと考えています。バージョンを“塩漬け”にしたまま変更による影響を考慮して運用するのではなく、変化を前向きに捉えるクラウド時代のセキュリティ思考へと導ける「トラステッド・アドバイザー」になることを目指しています。

最後に、これから受験を考えている方へ。
クラウドサービスの普及から10年以上が経ち、各クラウドベンダーが認定資格を提供していますが、それらはどうしてもベンダー依存の視点に偏りがちです。CCSKは、ベンダーに依存しない「クラウドセキュリティの標準」を学ぶ貴重な機会になります。クラウドを本質的に理解したい方にこそ、お勧めしたい資格です。

海外に学ぶSMBのクラウドセキュリティ基礎（CSP編）Microsoft(2)

コメントをどうぞ

海外に学ぶSMBのクラウドセキュリティ基礎（CSP編）Microsoft(1)に引き続き、今回は、アクセス制御の視点から、シンガポールサイバーセキュリティ庁のサイバーエッセンシャルズおよびサイバートラストマークに基づいて開発されたMicrosoft固有のガイドを紹介していく。

アイデンティティ／アクセス管理はクラウドユーザーの責任

Microsoft版ガイドでは、「サイバーエッセンシャルズマーク: クラウドセキュリティコンパニオンガイド」に従い、以下のような管理策について触れている。

[資産]
A1. 人々 – 従業員に、防衛の最前線となるノウハウを装備させる
A2. ハードウェアとソフトウェア – 組織が何のハードウェアとソフトウェアを所有しているかを知り、それらを保護する
A3. データ– 組織が何のデータを持っているのか、どこにあるのか、データをセキュア化しているのかについて知る
[セキュア化／保護]
A4. ウイルスとマルウェアの保護– ウイルスやマルウェアのような悪意のあるソフトウェアから保護する
A5. アクセス制御 – 組織のデータやサービスへのアクセスを制御する
A6. セキュアな構成 – 組織のハードウェアやソフトウェアのために、セキュアな設定を使用する
[アップデート]
A7. ソフトウェアのアップデート – デバイスやシステム上のソフトウェアをアップデートする
[バックアップ]
A8. 不可欠なデータのバックアップ– サイバーセキュリティインシデントを検知し、対応して、復旧の準備をする
[対応]
A9. インシデント対応 – サイバーセキュリティインシデントを検知し、対応して、復旧の準備をする

このうち「A5. アクセス制御 – 組織のデータやサービスへのアクセスを制御する」の中で、アクセス制御に関する要求事項や管理策を提示している。

「サイバーエッセンシャルズ」や「サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド」では、「A5. アクセス制御」のうちA.5.4 (a)のアカウント管理に関して、以下の通りクラウドプロバイダー共通の管理策を提示している。

【サイバーエッセンシャルズ】
A.5.4 (a) <要求事項>
アカウント管理を確立し、アカウントのインベントリを維持し、管理する必要がある。組織は、スプレッドシートを使用する、またはソフトウェアディレクトリサービスからリストをエクスポートするなど、さまざまな方法でこれを実現することができる。

【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】
[エンドユーザー組織(SaaSカスタマー)の責任]

  • エンドユーザー組織（SaaSカスタマー）が責任を負う。

<なぜこれが重要なのか>

  • アイデンティティ、資格情報、アクセス管理、および特権アカウントが不十分であることは、主要なクラウドセキュリティの懸念の一部である。
  • 組織が管理するSaaSサブスクリプションの数が増加する可能性がある。
  • さまざまな事業部門の業務ユーザーが、それぞれのSaaSアプリケーションにアクセスし管理する場合がある。
  • 各SaaSサブスクリプションにはそれぞれ固有のアイデンティティが存在する可能性がある。
  • その結果、組織は多数のアイデンティティを管理する必要があるかもしれない。
  • 各SaaSサブスクリプションは、アイデンティティを定義、表示、および保護する方法が異なる場合がある。

<組織は何をすべきか>

  • SaaSサブスクリプションへのアカウントのインベントリを追跡および監視する仕組みを実装する。
  • 多数のSaaSサブスクリプションおよびアイデンティティを管理する必要がある組織は、個々のSaaSサブスクリプションのパスワードを個別に管理するのではなく、アイデンティティプロバイダーを活用してシングルサインオン（SSO）ソリューションを通じてユーザーを認証することで、アイデンティティ管理をスケールすることができる。
  • SaaSサブスクリプションへのユーザーアクセスを制限することを検討する。例：ビジネスセキュリティポリシーに従う承認されたデバイスからのみユーザーがアクセスできるようにする。
  • 組織が「Bring Your Own Device（BYOD）」の方針を採用している場合は、リスクベースのアプローチを検討する。例：管理されていないBYODデバイスからのSaaSサブスクリプションへのアクセスを制限する。

-[クラウドプロバイダーの責任]
-[SaaSプロバイダーの責任]
(該当なし)
-[クラウドインフラストラクチャプロバイダー]
(該当なし)

これらを受けて、Microsoft版ガイドでは、以下のように管理策を提示している。

[エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]

  • CSAサイバーエッセンシャルマーク：クラウドセキュリティコンパニオンガイドを参照

[クラウドプロバイダーの責任]
-[SaaSプロバイダー(例. Microsoft 365)]

-[クラウドインフラストラクチャプロバイダー(例. Microsoft Azure)]

アカウント管理は、エンドユーザー組織（SaaSカスタマー）の責任範囲であるが、Microsoftの場合、Azure Active DirectoryやPowerShellスクリプトなど、固有のツールを利用した管理サポート策を提供している。これらのツールは、既存のオンプレミス環境と新たなクラウド環境を連携させる場合に重要な役割を果たすが、ユーザー組織の規模が拡大すると、アイデンティティ／アクセス管理が複雑になる。このような状況を支援するために、サードパーティプロバイダーによるIDaaS（Identity as a Service）などがある。IDaaSを利用する場合でも、最終的な責任は、ユーザー組織にあることを忘れてはならない。

参考までに、Google Workspaceでは、A.5.4 (a)に関して、以下のような管理策を提示している。

[Google Workspaceユーザーの責任]

  •  カスタマーは、自身のシステムアカウントユーザーを管理および追跡する責任を負う。この責任には、Google Workspaceユーザーアカウントを管理するために利用可能なツールを使用することが含まれる。

[Googleの責任]

  •  Google Workspaceは、カスタマーがユーザーやそのデバイスを簡単に追加し、管理できる集中型ダッシュボードを提供する。

オンプレミスとクラウドの連携環境で複雑化する物理的なアクセス制御

次に、A.5.4 (i)の物理的なアクセス制御については、以下の通りクラウドプロバイダー共通の管理策を提示している。

【サイバーエッセンシャルズ】
A.5.4 (i) <要求事項>
物理的なアクセス制御を実施し、認可された従業員や契約者のみが組織のIT資産および／または環境にアクセスできるようにする必要がある。たとえば、作業用端末を固定するためのケーブルロックの使用や、認証および承認された入室を行うためのカードアクセス式ドアロックの利用が挙げられる。
【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】
[エンドユーザー組織(SaaSカスタマー)の責任]
• エンドユーザー組織（SaaSカスタマー）は、物理的なアクセス制御について責任を負わない。
[クラウドプロバイダーの責任]
-[SaaSプロバイダー]
（該当なし）
-[クラウドインフラストラクチャプロバイダー]
• クラウドインフラストラクチャプロバイダーは、基盤となるクラウドインフラストラクチャの物理的なセキュリティに責任を負う。
• 主要クラウドインフラストラクチャプロバイダーは、物理的なセキュリティ対策に関するベストプラクティスを公開していることが一般的である。

これらを受けて、Microsoft版ガイドでは、以下のように管理策を提示している。

[エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]
（該当なし）
[クラウドプロバイダーの責任]
-[SaaSプロバイダー(例. Microsoft 365)]

  •  Microsoft Azureに関する情報を確認する。

-[クラウドインフラストラクチャプロバイダー(例. Microsoft Azure)]

物理的なアクセス制御は、エンドユーザー組織（SaaSカスタマー）の責任範囲外であるが、Microsoftの場合、クラウドプロバイダー（例. Microsoft 365、Microsoft Azure）としての管理状況をユーザー組織が確認できる仕組みになっている。

ただし、オンプレミス環境における物理的なアクセス制御について、クラウドプロバイダーは言及していない。参考までにGoogle Cloudの場合、「カスタマーは、自身のローカル環境における物理的なスペースおよび資産のセキュリティを確保する責任を負う。」と明記してある。ハイブリッド環境上のSaaSでは、ユーザーがオンプレミス環境とクラウド環境の間をシームレスに行き来しながら利用するのが普通だが、物理的なアクセス制御に関する責任分担は異なるので、注意が必要だ。

非アクティブなアカウントの維持管理は要注意

さらに、A.5.4 (k)の非アクティブなアカウントに関して、以下の通りクラウドプロバイダー共通の管理策を推奨している。

【サイバーエッセンシャルズ】
A.5.4 (k) <推奨事項>
長期間（例：60日間）非アクティブまたは休眠状態となっているアカウントは、削除または無効化されるべきである。
[クラウドプロバイダーの責任]
-[SaaSプロバイダー]
（該当なし）
-[クラウドインフラストラクチャプロバイダー]
（該当なし）

これらを受けて、Microsoft版ガイドでは、以下のように管理策を提示している。

[エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]
（該当なし）
[クラウドプロバイダーの責任]
-[SaaSプロバイダー(例. Microsoft 365)]

-[クラウドインフラストラクチャプロバイダー(例. Microsoft Azure)]

未使用のユーザーアカウントの場合、一定期間が経過すると、データの削除やサービスの無効化が行われる規定になっていることがあるので、クラウドユーザーは、定期的に未使用のユーザーアカウントを確認し、必要な措置を講じておく必要がある。

参考までにGoogle Cloudの場合、「カスタマーは、Google Workspaceアカウントを含むすべての非アクティブなユーザーアカウントを削除または無効化する責任を負う。」と明記している。

プロバイダーや政府機関が推奨する多要素認証（MFA）

A.5.4 (l)のパスワード管理に関して、以下の通りクラウドプロバイダー共通の管理策を提示している。

【サイバーエッセンシャルズ】
A.5.4 (l) <要求事項>
組織は、すべてのデフォルトのパスワードを変更し、強力なパスフレーズに置き換える必要がある。たとえば、12文字以上で、大文字、小文字、および／または特殊文字を含むべきである。
【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】
[エンドユーザー組織(SaaSカスタマー)の責任]

  •  SaaSサブスクリプションごとに別々のパスワードを維持・管理するのではなく、アイデンティティプロバイダーとSSOの使用に関するA.5.4(a)のガイダンスを参照のこと。
  • もし別々のパスワードを維持・管理する必要がある場合：
    • 安全なパスフレーズの使用を導入する。
    • パスフレーズが複数のSaaSサブスクリプション間で再利用されないようにする。
    • パスフレーズが複数のアカウント間で共有されないようにする。

[クラウドプロバイダーの責任]
-[SaaSプロバイダー]
（該当なし）
-[クラウドインフラストラクチャプロバイダー]
（該当なし）

これらを受けて、Microsoft版ガイドでは、以下のように管理策を提示している。

[エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]
（該当なし）
[クラウドプロバイダーの責任]
-[SaaSプロバイダー(例. Microsoft 365)]

パスワード管理についてはSaaSユーザーが責任を持っている。これに対してMicrosoftは、一貫してMFAの導入を推奨しており、シンガポールサイバーセキュリティ庁も、MFAの重要性を訴えている（https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2023-006）。

さらに、A.5.4 (o)の2要素／他要素認証に関しては、以下の通りクラウドプロバイダー共通の推奨事項として提示している。

【サイバーエッセンシャルズ】
A.5.4 (o) <推奨事項>
可能であれば、重要なシステムへの管理者アクセスには二要素認証（2FA）を使用するべきである。たとえば、機密情報や業務に重要なデータを含むインターネット向けシステムが該当する。組織はこれをさまざまな方法で実施することができる。例として、モバイル上の認証アプリケーションやワンタイムパスワード（OTP）トークンの使用が挙げられる。
[エンドユーザー組織(SaaSカスタマー)の責任]

  • SaaSサブスクリプションは公共のインターネット経由でアクセスされる可能性があるため、二要素認証（2FA）を導入して、SaaSサブスクリプションにアクセスするユーザーが本人であることを確認する必要がある。

[クラウドプロバイダーの責任]
-[SaaSプロバイダー]
（該当なし）
-[クラウドインフラストラクチャプロバイダー]
（該当なし）

これらを受けて、Microsoft版ガイドでは、以下のように管理策を提示している。

[エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]
（該当なし）
[クラウドプロバイダーの責任]
-[SaaSプロバイダー(例. Microsoft 365)]
• A.5.4 (l)を参照
-[クラウドインフラストラクチャプロバイダー]
• A.5.4 (l)を参照

ただし、昨今、シンガポールでは、中間者攻撃（MITM：Man-in-the-Middle Attack）、MFA疲労攻撃、セッションハイジャック／cookie盗難、認証コード／トークン窃盗などの手法を使ってMFAをバイパスする攻撃による被害が増加しており、シンガポールサイバーセキュリティ庁が注意喚起を行っている（https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2024-020/）。MFAを導入したからといって、セキュリティリスクを100%低減できるわけではない点に注意する必要がある。

今回は、アクセス制御に焦点を当てたが、たとえば取引先の環境に合わせて、Microsoft 365とGoogle Workspaceを併用しなければならないケースが多く見受けられる。そのような場合には、Google Cloud版ガイドとMicrosoft版ガイドを組み合わせて管理策を検討する必要があろう。

CSAジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司