CISSP試験勉強ノートDomain 5
還暦でも頑張る💪🏻！CISSP試験は今月末！
CISSP試験に向けた勉強を進めています。$200余分に払ってPeace of Mindってお手つき１回できる受験なので、最初の試験が９月30日、2度目は11月になる予定です。
ドメイン1から順にやるべきなのでしょうが、ドメイン1は一番出題頻度が高いようなので、真ん中からやってみようと思います。
今回はドメイン5の私の勉強方法をご紹介します。フルタイムで働く還暦おばさんなので、効率よく勉強したいなぁと切望してます。働きながら資格取得を目指す方の参考になれば幸いです。
1. まずは問題を解いてみる
私は、CISSPの公式問題集を活用しています。ドメイン5には100問の問題がありますが、働きながらの勉強ですので、一日50問ずつ解くことにしました。毎朝5時半から6時半までの1時間を使って問題に取り組み、まず自分の理解度を測ります。この段階では正解率が50%でしたが、勉強せずにこの結果ならまずまずだと感じました。
2. 間違えた問題を徹底的に復習
週末には、平日に解いた問題のうち間違えた問題を徹底的に復習します。その際、まずはChatGPTを活用しています。「このドメインから出題率が高いエリアを順に並べて。各エリアのキーワードも書いて」と指示すると、ドメイン5の重要エリアが一覧で出てきます。
3. 間違えた内容をエリア毎に整理
間違えた内容は、先ほどのエリア別リストにまとめて整理します。例えば、Kerberosについてよくわからなかった場合、エリア「セキュリティトークンとセッション管理」にKerberosの仕組みや、SSO（シングルサインオン）での役割、KDC（Key Distribution Center）、AS（認証サーバー）、TGT（チケット・グラント・チケット）、TGS（チケット・グラント・サービス）などの用語を一緒に書き込みます。
私はこの作業をNotionを使って行っています。ドメインごとにまとめた勉強ノートを作成し、後から何度も見返して暗記できるようにする予定です。
4. 徹底的に覚える
還暦のおばさんなので、若い頃のようにはスムーズに覚えられない部分もありますが、何度も見返して徹底的に覚えることが重要です。試験ははっきり言うと暗記！覚えるしかありません！勉強していてわからない部分が出てきたときは、初心者向けのイラスト入りのサイトも活用しています。このサイトがとても分かりやすく、私にとってありがたい存在です。
最後に
CISSPは難易度が高い試験ですが、計画的に勉強を進めていけば、還暦おばさんでも十分に合格できると思います。(思いたい！) 少しずつでも着実に進めていく予定です。
ChatGPTでまとめるのが面倒だぁ〜！という方、私のノートでよろしければご活用ください。以下はDomain 5内から試験に出る順番にエリアごとにまとめてみました。
私の勉強ノート:Domain5
Domain 5「識別と認証（Identity and Access Management: IAM）
1.アクセス制御モデル（Access Control Models）
- アクセス制御リスト（Access Control List, ACL)
各リソースに誰がどんな操作（読み取り、書き込み、実行）ができるかを定めたリスト。**個々のリソース**に対するアクセス権限のリスト。
- ロールベースアクセス制御（Role-Based Access Control, RBAC）:役割に基づいてアクセス権限を付与。例：管理者はフルアクセス、一般ユーザーは制限されたアクセス。ユーザーの**役割に基づいて**権限を管理。
- ABAC (Attribute-Based Access Control):属性に基づいて**アクセス権を決定するモデル。
- DAC (Discretionary Access Control): リソース所有者がアクセス権限を設定するモデル。多数の管理者を活用することによって高い拡張性を確保する。管理者たちは、自身のオブジェクトへのアクセスに関して、柔軟性のない強制アクセス制御（MAC）に合わせることなく意思決定することにより柔軟性を高める。
- 強制アクセス制御 (Mandatory Access Control, MAC):組織やシステムによって定義されたセキュリティポリシーに基づいてアクセス権を制御するモデル。ユーザーや管理者の裁量を許さず、ポリシーに従って厳格にアクセスが管理される。サブジェクトのラベルとオブジェクトのラベルに基づいて、アクセス権限が決まる。
Lattice（格子）-based MAC：情報は階層的に整理されていて、どの情報を見られるかが厳密に決められているイメージ。たとえば、学校の先生だけが生徒の成績を見られるように、システムも決められたルールに従って情報を管理している。
- 認証は、ユーザーが主張する身元を確認するプロセス。パスワードやバイオメトリクス（指紋や顔認証）、認証トークンなどが使用される。
- 信頼できるコンピューティングベース (Trusted Computing Base, TCB):システムのセキュリティポリシーを実行するために必要な**最小限のハードウェア、ソフトウェア、ファームウェアのセット。TCBが侵害されると、システム全体のセキュリティが脆弱になる可能性がある。
- アクセス制御マトリックス（Access Control Matrix）:システム内の各ユーザーやプロセスがどのリソースに対してどのような権限を持っているかを示す表。
MAC（強制アクセス Mandatory Access Control）モデルの２つの主要ポリシー
ビジビリティポリシー（BIBA Policy）
- 情報の機密性を保つことを目的とし、情報が下位から上位に流れるのを防ぎます（「書き込み」制御)。
書き込み、高い読み取り（No Write Up, No Read Down）
- No Read Down: ユーザーまたはプロセスは、自分よりも低い整合性レベルのオブジェクトからデータを読み取ることができない。つまり、高い整合性レベルから低い整合性レベルのデータを読み取ることは禁止。
- No Write Up:ユーザーまたはプロセスは、自分よりも高い整合性レベルのオブジェクトに対して書き込むことができない。つまり、低い整合性レベルから高い整合性レベルのデータへの書き込みは禁止。
利用例
- 軍事機関: 作戦計画や重要な戦略が意図しない変更を受けないようにするために使う。
- 政府機関: 政府の公式記録や機密情報が正確に保たれるようにするために使いう。
- 銀行でお金の取引データが間違って変更されないようにする。
- 病院で患者の治療記録が正確に保たれるようにする。
- 会社で重要なデータが不正に変更されないようにする。
ラベルポリシー（Bell-LaPadula Model）:
- 情報の機密性を保つことを目的とし、情報が上位から下位に流れるのを防ぎます（「読み込み」制御)。（例）「機密」にアクセスできる人はUnclassified（非機密）にはアクセスできない。
高い書き込み,低い読み取り（No Write Down、No Write Down)
- No Read Up（読み取りの禁止）: ユーザーは、自分の機密性レベルよりも高いレベルの情報を読むことができない。これにより、高い機密性レベルのデータが低いレベルのユーザーに漏れるのを防ぐ。
- No Write Down（書き込みの禁止）: ユーザーは、自分の機密性レベルよりも低いレベルの情報に書き込むことができない。これにより、低い機密性レベルのデータが高いレベルのユーザーによって変更されるのを防ぐ。
利用例
- 軍事機関や政府機関では、重要な情報が外部に漏れないようにこのモデルを使う。
- 企業や病院でも、機密情報が他の人に知られないようにこのモデルを使う。
LDAP(Lightweight Directory Access Protocol）
- LDAPは、ディレクトリサービス（人やグループの情報を管理する仕組み）のアクセスや操作のために使われるプロトコル。
ポート636との関係は？
- 通常、非暗号化の通信はポート389。安全な通信が必要な場合はポート636を使用し、SSL/TLSで暗号化されたLDAPSを使う。
Active Directory (アクティブ ディレクトリ）
基盤になる技術は、LDAP (Lightweight Directory Access Protocol）とX.500。
OpenLDAPのUserPassword属性の値
デフォルトでは、OpenLDAPは`{CRYPT}`形式でハッシュ化されたパスワードを使用するがセキュリティの観点からSSHA(Salted SHA-1）や他のより安全なハッシュアルゴリズムの使用が推奨される。設定ファイルでハッシュアルゴリズムを変更することで、より強力なセキュリティを確保することができる。
DN (Distinguished Name) と RDN (Relative Distinguished Name)
LDAP内で情報を特定するために使われる名前の形式。
- DN (Distinguished Name)
- LDAPディレクトリ内の特定のエントリを一意に識別するための完全な名前。
- 例: `cn=John Doe, ou=People, dc=example, dc=com`
- ここで、`cn=John Doe` がエントリの名前（RDN）、`ou=People` がそのエントリが属する組織単位、`dc=example, dc=com` がドメインを表します。
- RDN (Relative Distinguished Name)
- RDNは、DNの中でそのエントリを特定する部分的な名前。
- 例: 上記の例の `cn=John Doe` はRDNにあたる。
関係:
簡単に言うと、DNはフルアドレスで、RDNはその一部。LDAPは、そのアドレスを使って、ディレクトリ内のユーザーやリソースを管理する。
X.500
ネットワーク上でのユーザーやリソースの情報を管理・検索するための仕組み。LDAPやActive Directoryなど、さまざまなアイデンティティ管理システムの基盤となっている。
SASL (Simple Authentication and Security Layer）
認証部分をサポートするためにLDAPに統合されており、セキュリティを高める役割を果たしている。LDAPのSASLを使用することで、認証プロセスが標準化され、異なる認証メカニズムをシームレスにサポートできるようになる。
2. 認証（Authentication）
多要素認証 (Multi-Factor Authentication, MFA):
2つ以上の異なる要素を使用して、ユーザーの正当性を確認する認証方式。「知識」（例：パスワード）、「所有物」（例：トークン）、「自分自身」（例：指紋や顔認証）などを組み合わせる。
- 米国政府のCAC（Common Access Card）は、タイプ2認証要素の一例。CACは物理的なカードで、以下の要素が含まれる：
- カード: 物理的なカード（ハードウェア）
- スマートカード機能: 内部に電子証明書やセキュリティ情報が組み込まれている。
CER (Crossover Error Rate)
- バイオメトリクス認証システムの性能を評価するための指標です。CERは、本人拒否率（False Rejection Rate, FRR）と他人受け入れ率（False Acceptance Rate, FAR）が等しくなる点を示す。この値が低いほど、認証システムの精度が高いとされています。
- CERが低いということは、認証システムが適切に**正当なユーザーを受け入れ、不正なユーザーを拒否することができることを意味**します。
- **FRRとFARがニーズに合ったパフォーマンスレベルを提供していない場合**、ほかのバイオメトリクス認証システムを評価して比較する。
- 手のひらスキャンは静脈パターン（個人固有）。優れた認証システム。
- バイオメトリクス認証の保存サンプル：参照テンプレートという。Reference Template。
- バイトメトリックスシステムの問題：登録時間が長い場合（２，３分以上）、処理速度が遅い場合。
-
**TLS:**
1. **公開鍵と秘密鍵**: サーバーが持っているペアで、**公開鍵でデータを暗号化**し、**秘密鍵で復号化**する。
2. **セッションキー**: 通信が始まった後に使われる一時的な鍵で、**この鍵でデータを暗号化**して、やり取りを安全にする。
3. **証明書**: サーバーが本物であることを証明するためのデジタル証明書。これには**公開鍵**が含まれている。
**PORT：**
636、3269：SSL/TLS LDAPディレクトリー、グローバルカタログサービスのDefault
3268：非セキュアなグローバルディレクトリーサービス
389：非セキュアなLDAP
**認証プロトコル**:
- **SSO**
一度の認証で複数のシステムやアプリケーションにアクセスできる方式。パスワード管理の簡略化やユーザー体験の向上に寄与。
- **SAML (Security Assertion Markup Language)**: シングルサインオン (SSO) を**実現する**ためのプロトコル。
- **Kerberos,**
- **ADFS（Active Directory Federation Service）、**
- **CAS（Central Authentication Service）**
はSSOの実装。
- **SSOサードパーティー**について：信頼できるサードパーティーが予期しない認証サイトにリダイレクトする場合、意識啓発が最良の防御となる。
- **OAuth**
**ウェブアプリがユーザーの代わりに**他のサービスに安全にアクセスするための仕組み。OAuthを使用することで、**ユーザーが自分のパスワードを他のアプリケーションと共有することなく、外部のサービスにアクセス権を付与。**
- **OpenID Connect**: OAuthの上に構築されたユーザー認証のためのプロトコル。
**（古い）Radius (Remote Authentication Dial-In User Service)**:
Radiusは、ユーザーの認証や認可を行うためのプロトコル。主に無線ネットワーク、モデム、ネットワークデバイスに使用。ネットワークアクセスサーバーを利用して中央のRADIUSサーバーにアクセスを要求する。
RADIUSデフォルト設定と通信プロトコルの関係
- **UDP**はRADIUSの**デフォルトの通信プロトコル**で、主に認証や承認、アカウンティングに使用。
- **TCP**は、必要に応じて設定で使用可能な**信頼性の高いプロトコル**。
- **TLS**は、RADIUS通信を**安全に保つための暗号化手段**で、オプションとして使用。
**（改良版）Diameter**:
Radiusの後継プロトコルで、より高いセキュリティと柔軟性を提供。認証、認可、アカウンティング（AAA）を統合してサポートし、複雑なネットワーク環境やモバイル通信に対応できるように改良されている。
**（最新）TACACS＋:**
ネットワークデバイスに使用。ネットワーク管理者がルータやスイッチなどのネットワーク機器に対するアクセスを制御するために、特にCisco製品で多く利用
## 3. セキュリティトークンとセッション管理（Security Tokens and Session Management）
**セッション管理 (Session Management)**:
ユーザーがシステムにログインしている間、そのセッションを管理するプロセス。セッションのタイムアウトやセッションIDの保護を通じて、不正アクセスからユーザーを守る。
### **Kerberos の仕組み**
**認証プロトコル**: **Kerberos**は、ユーザーとサービスの間の認証を提供するためのプロトコルとして説明されます。特に、チケットベースの認証システムとして、信頼できるサードパーティ（**KDC: Key Distribution Center）**を使用して認証を行います。
**アクセス制御**: Kerberosは、ユーザーがアクセスしようとしているリソースに対して適切なアクセス権を持っているかどうかを確認するためにも使用されます。
Kerberosのクライアントとサーバーの時刻が同期していないと、**認証に失敗する可能性が高くなる**。
- **チケットの無効化**: サーバーが受け取ったチケットが古いものだと判断して無効とみなす
- **リプレイ攻撃の防止**: Kerberosはリプレイ攻撃（同じ認証情報を再利用する攻撃）を防ぐため、チケットの発行時刻と受信時刻を比較。時刻がずれていると、正当なチケットであっても攻撃とみなされることがあります。
- **セッションタイムアウト (Session Timeout)**:
一定時間ユーザーが操作を行わない場合、自動的にそのセッションを終了させるメカニズム。これにより、放置されたセッションが悪意のある第三者に乗っ取られるリスクを防ぐ。
**リアルム (Realm)**: Kerberosが動作する範囲を定義するもの。企業や組織内のドメインを意味することが多く、異なるリアルム間で信頼関係を築くことができます。
**シングルサインオン (SSO):** Kerberos, KrptoKnight, SESAMEはシングルサインオンシステム。
**KDC (Key Distribution Center)**: 中心的な役割を果たす信頼できる第三者。このサーバーには、AS（Authentication Server）とTGS（Ticket Granting Server）が含まれます。
**KDC**はUserのパスワードを利用して、その**ハッシュで対称鍵**を暗号化する。**暗号化された対称鍵と、暗号化されTimestampされたTGTの両方がクライアントに送信**される。
Windows は認証にKerberosを使用する。
- **セッションハイジャック (Session Hijacking)**:
攻撃者がユーザーのセッションIDを盗み、正当なユーザーになりすましてアクセスする攻撃手法。Cookieの盗難や通信傍受によってセッションハイジャックが行われる。
- **AS (Authentication Server)**: 初期認証を行い、ユーザーに**TGT (Ticket Granting Ticket)**を発行。
- **TGS (Ticket Granting Server)**: **TGT**を基に、アクセスしたいサービスに対して使用する**サービスチケット (Service Ticket)**を発行。
- **TGT (Ticket Granting Ticket)**: ユーザーが一度ログインした後に再度パスワードを入力せずに、他のリソースにアクセスできるために使用されるチケット。
- **セキュリティトークン**:
- **JWT (JSON Web Token)**: 認証や情報の伝達に使用されるトークン。
- **SAMLトークン**: ユーザー認証情報を含むトークン。
## **トークンタイプ:**
- **同期トークン:**
特定の時間間隔（例えば1分ごと）で新しいトークンをcreate。これはサーバー側の時計とユーザーのデバイス上の時計が同期しているため、両者が同じトークンを生成できる仕組み。このように、一定の時間ごとにトークンが変わるため、トークンが盗まれても短期間で無効になるためセキュリティが高まる。
- **静的トークン（Static Token）**
ユーザーが使う固定の値（例: パスワードやPINコード）のことです。このトークンは認証のたびに同じ値が使用されます。シンプルですが、もしトークンが盗まれた場合、セキュリティが脆弱になるため、通常は他の認証手段と組み合わせて使用される。
****
**RESTful API**
**ウェブサイトやアプリがデータをやり取りするためのルール**。
- **リクエストとレスポンス**: ウェブサイトやアプリがサーバーにリクエストを送ると、サーバーがそのリクエストに応じたデータを返す。
- **HTTPメソッド**: データの取得や更新に使う指示が、`GET`（データを取得）、`POST`（データを作成）、`PUT`（データを更新）、`DELETE`（データを削除）などで示される。
- **リソース**: データは「リソース」と呼ばれるもので、URL（ウェブアドレス）でアクセス。例えば、`/users`はユーザー情報のリソースのこと。
- **非同期トークン：**
ユーザーがデバイス上で生成したトークンをサーバー側に送信し、サーバーがそのトークンを検証することで認証を行います。このプロセスでは、トークンの生成に時間の同期が必要ないため、サーバーとデバイスの時計が一致している必要はありません。代わりに、チャレンジとレスポンス（Challenge-Response）を基にトークンが生成されます。これも多要素認証（MFA）の一部として使われ、特にセキュリティが求められる場面で活用されます。
**OpenID Connect**は、ユーザーのアイデンティティを確認し、プロファイル情報を取得するための認証技術。**RESTful API**を使って、ユーザーのログインや情報取得を行う。OpenID Connectの認証リクエストやトークン取得は、RESTful API経由で行われ、データはJSON形式でやり取りされる。
OpenID Re-writing partyがOpenIDプロバイダへのRedirectを許可されると？
偽のOpenIDプロバイダーにクライアントを誘導するフィッシング攻撃が可能になり、有効な資格情報が取得される可能性がある。OpenIDプロバイダーのURLはクライアントから提供されるため、OpenIDRe-wiritngPartyは誤ったプロバイダーを選択できない。
- **CSRFトークン：**
フォーム送信時に含まれることで、不正なリクエストを防ぎます。サーバーはこのトークンを確認し、正しい場合にのみリクエストを受け入れます。**CSRF（クロスサイトリクエストフォージェリ）**は、**悪意のあるサイトがユーザーのブラウザを使って**、**ユーザーが意図しないリクエストを送信させる攻撃**です。
***リクエストの確認**: ユーザーからの正当なリクエストかどうかをチェックする。
***攻撃の防止**: 他人が不正に操作するのを防ぐ。
## 絶対覚える用語と説明
- **プロビジョニング (Provisioning)**:
新しいユーザーアカウントを作成し、そのユーザーに必要な権限やアクセス権を付与するプロセス。これには、ユーザー情報の登録、権限の付与、変更、解除が含まれる。
- プロビジョニングサービスとは？：システムやネットワークにおいて、ユーザーやリソース（例：デバイス、アプリケーション）のアクセスや権限を自動的に設定・管理するサービス。
**X.500とどう関係があるのか？**
- **X.500**：ネットワーク上でのユーザーやリソースの情報を管理・検索するための仕組み。LDAPやActive Directoryなど、さまざまなアイデンティティ管理システムの基盤となっている。
- **X.500**：プロビジョニングサービスが利用するユーザー情報の基盤を提供し、プロビジョニングサービスはその情報を使って、ユーザーやリソースの管理を効率化します。この連携により、組織内の**アクセス管理が一元化**され、セキュリティと運用効率が向上する。
- **JITプロビジョニング (Just-In-Time Provisioning):**
ユーザーがアクセスをリクエストした時点で、必要なリソースや権限を即座にプロビジョニングする手法。リソースの無駄を防ぎ、効率的なアクセス管理を実現。オンデマンドでリソースを割り当てる。
## 4. アクセス制御リスト（Access Control Lists, ACL）
- **アクセス制御リスト（Access Control List, ACL）**:各リソースに誰がどんな操作（読み取り、書き込み、実行）ができるかを定めたリスト。**個々のリソースに対するアクセス権限のリスト**。
- **アクセス制御 (Access Control)**:
ユーザーやシステムがリソースにアクセスできる権限を制御する仕組み。これにより、誰がどのリソースにアクセスできるか、どの操作が可能かが管理される。
**例：論理アクセス制御、物理アクセス制御。**
- **物理アクセス制御 (Physical Access Control)**:
データセンターやサーバールームなど、物理的な設備へのアクセスを制限する手法。例として、バイオメトリクスやIDカードが使用される。ロックは望ましくなアクセスを防止する防止コントろーりで物理コントロールでもある。
- **論理アクセス制御 (Logical Access Control)**:
パスワードやアクセス制御リスト（**ACL**）など、ソフトウェアベースの手段でリソースへのアクセスを制御する方法。
- **パスワードハッシュ化 (Password Hashing):**
パスワードを安全に保存するために、元のパスワードを**ハッシュ関数で不可逆に変換する手法**。**ソルト**を追加してハッシュ化すると、**辞書攻撃やレインボーテーブル攻撃を防ぐ**ことができる。
- **特権クリープ**
時間とともに徐々に蓄積された過剰な特権に関連する問題であり、複数の役割の間で特権が解除されずに残ることが原因です。
- **過剰な特権**は、特定の役割に対して意図的または無意識に必要以上の特権が付与される状況を指す。
**EコマースアプリケーションがGoogleUser向けにアカウントを作成する場合、パスワードはどこに保存される？**
**パスワードはアプリケーションに保存**されない。アプリケーションはGoogleの認証システムを通じてアクセストークンを取得し、それを使ってユーザー情報を管理。**Googleのアカウント管理システムでは**、ユーザーのパスワードは**ソルト付きハッシュで保存される。**これにより、パスワードのセキュリティが確保され、万が一データベースが漏洩しても、**元のパスワードが簡単に解読されることはない。**
- **特権アクセス管理 (Privileged Access Management, PAM)**:
特権アカウントの使用を監視し、管理するためのシステム。特権アカウントのセッションを記録し、不正使用の監視を行う。また、アクセスの制限や最小権限の原則に基づいたアクセス制御も行われる。
- **特権アカウント (Privileged Account):**
管理者や特定のシステム操作を行うための高い権限を持つアカウント。これらのアカウントは、システム全体や重要なデータにアクセスできるため、厳格な管理が必要。
- **最小特権の原則 (Principle of Least Privilege)**:
ユーザーやシステムに必要最低限の権限のみを付与するセキュリティ原則。これにより、アカウントが侵害された場合のリスクを最小限に抑えることができる。
- **銀行ウェブサイトでのUser Identity の証明**は、Userの信用報告書に基づく質問など、銀行とUserの両方が持っている情報を使用する。
- **フェデレーションアイデンティティ管理** (Federated Identity Management, **FIM**):異なる組織間でID情報を共有し、他の信頼できる組織の認証を利用してアクセスする仕組み。
- **Constrained Interface:** アクセス制御の中で、特定のユーザーやアプリケーションが許可された機能やデータにしかアクセスできないようにする技術。
**Clark-Wilson Model**は、データが正しく保たれるようにするセキュリティモデルです。主なポイント：
1. **データ操作の制限**: データは、特定のルールに従って動作する信頼できるプログラムを通じてのみ変更される。
2. **整合性維持**: データの操作は、事前に決められた手順に従って行われる。
例：**ビジネスシステム**: 銀行や商業アプリケーションなどで、データが正しく管理されるようにするために使われます。
**Brewer-Nash Model**（Chinese Wall Model）：
- **目的**: 競争や利益相反を防ぐために、ユーザーが異なる種類の機密データにアクセスするのを制限する。
- **使い方**: ユーザーが一つのデータにアクセスすると、そのデータと競合する他のデータにはアクセスできなくなる。
例：**企業内**: 例えば、同じ会社内で競争する部門が機密情報を管理する際に使う。
## **5. コンテキストベース制御（CBAC：Context-Based Access Control）**
**時間ベース制御（Time-Based Controls）**
**文脈に依存した制御（Context-Based Access Control, CBAC**）**の一種**。文脈に依存した制御は、アクセス権を決定する際に、単にユーザーのIDや役割だけでなく、時間、場所、使用するデバイスなど、さまざまな**条件（文脈）を考慮**する。
過去のCISSP試験に関連するContext-Based Access Control (CBAC)の問題例：
### 問題例 1:
**質問:** Context-Based Access Control (CBAC) でアクセスが許可される条件に含まれるものはどれか？
- A) ユーザーの識別子のみ
- B) デバイスの種類やネットワークの状態
- C) ユーザーのパスワードの強度
- D) アプリケーションのバージョン番号
**正解:** B) デバイスの種類やネットワークの状態
### 問題例 2:
**質問:** Context-Based Access Control (CBAC) の主な利点は何か？
- A) 全てのリクエストに対して同じアクセス権を提供する。
- B) アクセス制御は事前に決められたルールに基づいて動的に変更される。
- C) ユーザーがシステムにアクセスする際にパスワードを常に再入力させる。
- D) アクセス制御はサーバーの稼働状態に依存する。
**正解:** B) アクセス制御は事前に決められたルールに基づいて動的に変更される。
### 問題例 3:
**質問:** CBACに関する以下の説明のうち、正しいものはどれか？
- A) CBACはユーザーの役割に基づいてアクセスを許可する。
- B) CBACはアクセスリクエストの文脈に基づいて許可を決定する。
- C) CBACはパスワードポリシーを強制するための仕組みである。
- D) CBACは静的なルールに基づいてアクセスを許可する。
**正解:** B) CBACはアクセスリクエストの文脈に基づいて許可を決定する。
**静的トークン（Static Token）**
リクエストの正当性を確認するためのトークン。ウェブサイトがリクエストが正当かどうかを確認する。主に以下の用途がある：
- **リクエストの確認**: ユーザーからの正当なリクエストかどうかをチェックする。
- **攻撃の防止**: 他人が不正に操作するのを防ぐ。
- 通常**CSRFトークン**として知られ、フォーム送信時に含まれることで、不正なリクエストを防ぐ。サーバーはこのトークンを確認し、正しい場合にのみリクエストを受け入れる。
- **CSRF（クロスサイトリクエストフォージェリ）**は、悪意のあるサイトがユーザーのブラウザを使って、ユーザーが意図しないリクエストを送信させる攻撃です。
### 問題例 4:
**質問:** Context-Based Access Control (CBAC) はどのような場面で使用されるべきか？
- A) 全てのアクセスを一律に制御する必要がある場合
- B) 動的なリスク評価に基づいてアクセスを制御する必要がある場合
- C) 管理者がすべてのアクセスリクエストを手動で承認する場合
- D) ユーザーの役職に基づいてアクセス制御を行う場合
**正解:** B) 動的なリスク評価に基づいてアクセスを制御する必要がある場合
動的なリスク評価に基づくアクセス制御は、ユーザーがアクセスしようとする時の状況（場所、時間、デバイスなど）をリアルタイムで判断し、リスクが高ければアクセスを制限する方法です。例えば、いつもとは違う場所や時間からのアクセスだと、システムが危険と判断して、追加の確認が必要になることがあります。
## 6. 時間ベース制御（Time-Based Controls）
- **時間制限アクセス**: アクセス権限を時間に基づいて制御する方法。
**問題例 1**：
「会社では、従業員が会社のデータベースにアクセスできる時間を午前8時から午後6時までに制限したいと考えています。この目的のために、最も適切なアクセス制御方法は何ですか？」
**解答例**：
「時間制限アクセス制御を使用する。これは、特定の時間帯にアクセスを制限することで、業務時間外の不正アクセスを防ぐ手段として有効です。」
**問題例 2**：
「組織は、機密データに対するアクセスを従業員の業務時間内のみに制限することで、セキュリティリスクを最小限にしたいと考えています。この要求を満たすために、どのアクセス制御メカニズムを使用すべきですか？」
**解答例**：
「時間制限アクセス制御を実装することで、業務時間外のデータアクセスを防ぎ、セキュリティリスクを低減します。」
- **時間ベース制御**: 特定の時間にのみアクセスを許可する制御。
**問題例 1:**
**質問:**
ある企業は、従業員が業務時間中にのみ特定のシステムにアクセスできるようにしたいと考えています。これを実現するために最も適切なアクセス制御のタイプはどれですか？
**選択肢:**
1. ロールベースアクセス制御（RBAC）
2. マンドトリーアクセス制御（MAC）
3. 時間ベースアクセス制御
4. ルールベースアクセス制御
**正解:** 3. 時間ベースアクセス制御
---
**問題例 2:**
**質問:**
企業は、社員が業務時間外に重要なデータベースにアクセスするリスクを減らすため、どのアクセス制御方法を実施すべきですか？
**選択肢:**
1. アクセス制御リスト（ACL）
2. 時間制限付きアクセス制御
3. コンテンツベースアクセス制御
4. マルチファクタ認証（MFA）
**正解:** 2. 時間制限付きアクセス制御
## 7. 脅威と脆弱性（Threats and Vulnerabilities）
- **脅威モデル**: セキュリティリスクを特定し分析するためのモデル。
- フィッシングはアクセス制御のメカニズムへの攻撃ではない。結果として資格情報が盗まれることがあるが、攻撃自体は人間に対するもの。
- 辞書攻撃、中間者攻撃はアクセス制御システムを標的にする。
- **Raceコンディション**：二つ以上のプロセスが同一リソースへのアクセスを要求した場合、発生する。
### **1. パスワードの脆弱性**
**質問:**
企業で使用されているパスワードの複雑性が低い場合、どのような脅威に対して脆弱である可能性がありますか？
**選択肢:**
1. ソーシャルエンジニアリング
2. ブルートフォース攻撃
3. バッファオーバーフロー
4. SQLインジェクション
**正解:** 2. ブルートフォース攻撃
---
### **2. 多要素認証の脅威**
**質問:**
多要素認証（MFA）を導入している企業で考えられる脅威はどれですか？
**選択肢:**
1. マルウェア
2. フィッシング攻撃
3. 認証情報のハッシュ化
4. ブルートフォース攻撃
**正解:** 2. フィッシング攻撃
---
### **3. セッションハイジャック**
**質問:**
ウェブアプリケーションで発生するセッションハイジャック攻撃に対する効果的な防御策はどれですか？
**選択肢:**
1. 強力なパスワードポリシーの実施
2. セッションIDの暗号化
3. ソーシャルエンジニアリング教育
4. 物理的セキュリティの強化
**正解:** 2. セッションIDの暗号化
### **4. フィッシング攻撃**
**質問:**
従業員がフィッシング攻撃を受けた場合、最も直接的なリスクはどれですか？
**選択肢:**
1. 個人情報の盗難
2. サービス拒否（DoS）攻撃
3. SQLインジェクション
4. クロスサイトスクリプティング（XSS）
**正解:** 1. 個人情報の盗難
---
### **5. バッファオーバーフローの脅威**
**質問:**
バッファオーバーフローの脆弱性があるプログラムに対して、最も一般的な脅威はどれですか？
**選択肢:**
1. 不正なコードの実行
2. 認証情報のハッシュ化
3. データの暗号化
4. パスワードのリセット
**正解:** 1. 不正なコードの実行
- **脆弱性評価**: システムの脆弱性を評価するプロセス。
### **1. Raceコンディションの定義**
**質問:**
Raceコンディションとはどのようなセキュリティ脆弱性を指しますか？
**選択肢:**
1. ソフトウェアが複数のスレッドによって同時にアクセスされるときに発生する予期しない動作
2. ネットワーク通信が盗聴される脆弱性
3. 認証情報が誤って共有されるリスク
4. 暗号化アルゴリズムの欠陥
**正解:** 1. ソフトウェアが複数のスレッドによって同時にアクセスされるときに発生する予期しない動作
---
### **2. Raceコンディションの防止策**
**質問:**
Raceコンディションを防止するために有効な方法はどれですか？
**選択肢:**
1. マルウェア対策ソフトウェアのインストール
2. 入力バリデーションの実施
3. ロック機構や同期機構を使用して、同時アクセスを制御する
4. パスワードの強化
**正解:** 3. ロック機構や同期機構を使用して、同時アクセスを制御する
---
### **3. Raceコンディションの影響**
**質問:**
Raceコンディションが発生すると、どのような結果になる可能性がありますか？
**選択肢:**
1. 認証の失敗
2. データの不整合や予期しないシステム動作
3. ネットワーク遅延
4. パフォーマンスの向上
**正解:** 2. データの不整合や予期しないシステム動作
---
### **4. 競合状態の具体例**
**質問:**
どのシナリオがRaceコンディションのリスクが高いと言えますか？
**選択肢:**
1. 複数のスレッドが同じリソースに同時にアクセスし、そのリソースを変更する場合
2. 単一のプロセスがデータベースにアクセスする場合
3. ユーザーがウェブフォームに入力する場合
4. クラウドサービスの利用
**正解:** 1. 複数のスレッドが同じリソースに同時にアクセスし、そのリソースを変更する場合
---
### **5. Raceコンディションの検出**
**質問:**
Raceコンディションを検出するために最も適した方法はどれですか？
**選択肢:**
1. コードレビューと並行処理のテスト
2. ウイルススキャン
3. 入力フィルタリングの実施
4. 認証ログの監視
**正解:** 1. コードレビューと並行処理のテスト
## KEYWORDS
### **1. 認証 (Authentication)**
- **MFA (Multi-Factor Authentication)**: 多要素認証
- **SFA (Single-Factor Authentication)**: 単一要素認証
- **Password-based Authentication**: パスワード認証
- **Biometric Authentication**: 生体認証
- **Fingerprint**: 指紋
- **Iris Scan**: 虹彩認証
- **Facial Recognition**: 顔認識
- **Token-based Authentication**: トークン認証
- **Synchronous Tokens**: 同期トークン
- **Asynchronous Tokens**: 非同期トークン
- **Static Tokens**: 静的トークン
- **Password Vaults**: パスワード管理
- **Password Complexity and History**: パスワードの複雑性と履歴:
**Password Complexity and History**（パスワードの複雑性と履歴）は、アカウントのセキュリティを高めるためのルールです。
**Password Complexity (パスワードの複雑性)**
- **内容**: パスワードに大文字、小文字、数字、記号を含める。
- **例**: `P@ssw0rd!2024`（複雑なパスワード）
**Password History (パスワード履歴)**
- **内容**: 過去に使ったパスワードを記録し、一定回数以上の再使用を禁止する。
- **例**: 最後の10回のパスワードは再使用できない。
これらのルールにより、パスワードのセキュリティが強化され、アカウントが守られます。
- **Knowledge-Based Authentication (KBA)**: 知識ベース認証
- **Context-Based Authentication**: 文脈ベース認証
- **Behavioral Biometrics**: 行動的生体認証
### **2. 認可 (Authorization)**
- **RBAC (Role-Based Access Control)**: ロールベースアクセス制御
- **ABAC (Attribute-Based Access Control)**: 属性ベースアクセス制御
- **MAC (Mandatory Access Control)**: 強制アクセス制御
- **Lattice-Based Access Control**: 格子ベースアクセス制御
- **DAC (Discretionary Access Control)**: 任意アクセス制御
- **Context-Based Access Control**: 文脈ベースアクセス制御
- **Rule-Based Access Control**: ルールベースアクセス制御
### **3. アクセス制御モデル (Access Control Models)**
- **Bell-LaPadula Model**: 機密性モデル
- **Biba Model**: 完全性モデル
- **Clark-Wilson Model**: 商業分野での完全性モデル
- **Brewer-Nash Model (Chinese Wall)**: 利益相反モデル
- **Non-Discretionary Access Control**: 非任意アクセス制御
- **Constrained Interface**: 制約付きインターフェイス
### **4. アクセス制御技術 (Access Control Technologies)**
- **Single Sign-On (SSO)**: シングルサインオン
- **Kerberos**: チケットベースの認証システム
- **TGS (Ticket Granting Service)**: チケット発行サービス
- **KDC (Key Distribution Center)**: 鍵配布センター
- **LDAP (Lightweight Directory Access Protocol)**: ディレクトリサービスプロトコル
- **DN (Distinguished Name)**: 識別名
- **RDN (Relative Distinguished Name)**: 相対識別名
- **SASL (Simple Authentication and Security Layer)**: 認証とセキュリティ層
- **OAuth**: オーソライゼーションフレームワーク
- **OpenID Connect**: 認証レイヤー
- **RADIUS (Remote Authentication Dial-In User Service)**: リモート認証サービス
- **UDP, TCP, TLS**: プロトコル
- **TACACS+ (Terminal Access Controller Access-Control System Plus)**: AAAプロトコル
- **Diameter**: RADIUSの拡張版
### **5. アクセス制御ポリシー (Access Control Policies)**
- **ACL (Access Control List)**: アクセス制御リスト
- **Time-based Access Control**: 時間ベースアクセス制御
- **Location-based Access Control**: 位置ベースアクセス制御
### **6. アイデンティティ管理 (Identity Management)**
- **Identity Federation**: アイデンティティ連携
- **Identity Provisioning**: アイデンティティプロビジョニング
- **Identity Governance**: アイデンティティガバナンス
- **Just-in-Time Provisioning**: ジャストインタイムプロビジョニング
### **7. 認証および認可のプロトコルと標準 (Protocols and Standards)**
- **SAML (Security Assertion Markup Language)**: 認証情報の標準
- **XACML (eXtensible Access Control Markup Language)**: アクセス制御の標準
- **SPML (Service Provisioning Markup Language)**: サービスプロビジョニングの標準
### **8. アクセス制御の脅威と脆弱性 (Threats and Vulnerabilities)**
- **Race Condition**: 競合状態
- **Time of Check/Time of Use (TOC/TOU)**: チェック時/使用時の競合
- **Crossover Error Rate (CER)**: 交差誤り率
- **False Acceptance Rate (FAR)**: 誤受理率
- **False Rejection Rate (FRR)**: 誤拒否率
- **Replay Attack**: リプレイ攻撃
- **Man-in-the-Middle Attack**: 中間者攻撃
### **9. 監査と報告 (Auditing and Reporting)**
- **Access Review**: アクセスレビュー
- **Audit Logs**: 監査ログ
- **Compliance Monitoring**: コンプライアンスモニタリング
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？