@baku2san(taka)

2025/春情報処理安全確保支援士無事合格

Posted at 2025-07-03

背景

Web アプリ開発に久しぶりにかかわることになった中で、自分が一番知ってそうな状態になった。
マジで？って思ったけど、変えられない現実なので、自分を変えることにした。

で、考えたのは、

知識としてのセキュリティは大切

AI と話すにしても、専門用語で指示しないと面倒なので、
久しぶりに資格勉強するか！と心に決めたのでした。

幸い、上司が本も買ってくれたので頑張ろう！っていう気持ちも沸き立ちました

実際にやったこと

二か月前までは、なんとなくの二ノ宮金次郎（あ、夏目漱石じゃなかった
一か月前までは、本付属の Webアプリ問題集で、午前２つは Rank A へ
最後の一か月、自腹で午後問題集を買ってきて、娘が寝た後に２．３問の問題を毎日解く
解く際にわからなかったり、説明できそうにない言葉を Copilot さんと壁打ちしながら、理解促進。

あとがき

理解は、間違えをしながら深まっていくもの、と考えているので、8割あってれば OK と考えて進みました。

無事合格できて、ほんとほっとしました。
娘にも褒められて幸せな一日でした 😍

以降は、Copilot 訓と一緒に勉強した記録。ゆえに、間違いも含むだろうから注意。

ISMS

ISMS(情報セキュリティマネジメントシステム) が構築されているか？
- 証拠の確認：文章化されたセキュリティポリシー、運用手順、リスク管理文書
- 認証の有無：ISO 27001 の認証
- 実施状況レビュー：定期的な内部監査・外部監査
情報セキュリティポリシーが存在している？
- 文書化の有無：文書化され、利用者がアクセスできる
- トップマネジメントの承認：経営陣によって承認されている
- 従業員教育：従業員に教育し、理解されている
情報セキュリティポリシーは定期的に見直されている？
- レビュー記録：レビューの最後の記録。年一の見直し
- 変更履歴：変更の履歴と理由の記録
- 関連規制の反映：法的要件や業界企画の変更の反映
情報セキュリティポリシーは機能している？
- モニタリングとレビュー：遵守状況を監視する仕組みがあるか
- 事例の評価：インシデント記録やその対処方法を確認して判断
- 従業員意識：日常業務でポリシーを正しく順守しているか

解凍指南

文書

80%埋める
質問文の最後を回答にいれる。
- 理由は？　ーだから
- 方法は？　－という方法
- 作業は？　ーという作業
５W1Hを入れる。
- 定期的に・・（When

用語

CISOは「Chief Information Security Officer」

https://www.meti.go.jp/policy/netsecurity/mng_guide.html

三原則

経営者のリーダーシップが重要
サプライチェーン全体にわたる対策への目配り
社内外関係者との積極的なコミュニケーション

NISC（National center of Incident readiness and Strategy for Cybersecurity）

日本の機関: 内閣官房に設置されている組織で、サイバーセキュリティに関する政策を推進しています。

主な役割: サイバー攻撃の未然防止、重要インフラの防護、政府機関の情報セキュリティ対策の統一基準作成など2。

設立: 2015年に「サイバーセキュリティ基本法」に基づいて設置されました。

NIST（National Institute of Standards and Technology）

アメリカの機関: アメリカ合衆国商務省の配下にある技術部門で、非監督機関です。

主な役割: 計量学や標準規格の進歩を通じて技術革新を促進し、産業競争力を高めること4。

設立: 1901年に設立され、1988年に現在の名称に変更されました。

SASE（Secure Access Service Edge）

ネットワークとセキュリティを統合したクラウドベースのフレームワークです。2019年に米国の調査会社ガートナーが提唱した概念で、特にテレワークやクラウド利用が増加する現代の環境に適したセキュリティ対策として注目されています2.

主な特徴

ネットワークとセキュリティの統合:

従来の境界型セキュリティ（社内ネットワークと外部ネットワークを分ける方式）では対応が難しい課題を解決するために設計されています。

ネットワーク機能（例: SD-WAN）とセキュリティ機能（例: ZTNA、CASB、FWaaS）を一体化して提供します2.

ゼロトラストの考え方:

「すべての通信を信用しない」というゼロトラストセキュリティの理念を実現するための具体的な仕組みとして機能します2.

クラウドベースの提供:

クラウドサービスとして提供されるため、企業ネットワークやリモート環境から安全にアクセスできる仕組みを構築します2.

メリット

セキュリティ対策の強化。

運用・管理の効率化。

コスト削減とパフォーマンス向上2.

SASEは、特にハイブリッドワークやクラウド利用が進む企業にとって重要なセキュリティソリューション

ID

アカウント管理

共同利用せず
標準化された手続
速やかに抹消

特権ID

最小権限の原則
相互牽制
事前申請性（期間の制限）
ログと確認
ログの捜査権限分離

AAAフレームワーク

ネットワークセキュリティの基本概念であり、以下の3つの要素を指します2:

Authentication（認証）: ユーザーが本人であることを確認するプロセスです。これにより、不正アクセスを防ぎます。例えば、パスワードや生体認証が使用されます。

Authorization（認可）: 認証されたユーザーに対して、アクセス権限を付与するプロセスです。これにより、ユーザーがアクセスできるリソースを制限し、情報漏洩のリスクを軽減します。

Accounting（監査）: ユーザーのアクティビティを記録・監視するプロセスです。これにより、不正アクセスの兆候を早期に発見し、システムの利用状況を把握することができます。

プロビジョニング

システムやアプリケーションに必要なユーザーのアクセス権限や役割を効率的に設定・管理するプロセスを指します。これは新しいユーザーの登録や、既存ユーザーの権限変更・削除などを含み、特に企業において重要な役割を果たします。

プロビジョニングの具体的な例

新規アカウントの作成新しい従業員が入社した際に、その人に必要なシステムのアカウントやアクセス権を設定するプロセスです。

権限の変更従業員の役割が変更された場合に、それに応じてアクセス権限を更新します。例えば、部署異動に伴うファイルアクセスの権限変更などが該当します。

アカウントの削除従業員が退職した場合、セキュリティリスクを回避するためにすべてのアカウントやアクセス権を削除するプロセスが行われます。

FIDO認証（Fast Identity Online）

パスワードを使用せずに本人認証を行う技術で、セキュリティと利便性を両立するために設計された国際規格です。従来のパスワード認証の課題を解決するために、公開鍵暗号方式を利用して認証を行います。

主な特徴
パスワードレス認証: パスワードを使用せず、指紋認証や顔認証などの生体認証を活用します。

公開鍵暗号方式: ユーザーのデバイスに秘密鍵を保存し、サーバーには公開鍵のみを登録します。これにより、秘密情報がネットワーク上に流れることを防ぎます。

多要素認証の実現: 生体情報やデバイス認証を組み合わせることで、より強固なセキュリティを提供します。

メリット
セキュリティの向上: パスワード漏洩のリスクを排除。

利便性の向上: ユーザーがパスワードを覚える必要がない。

プライバシー保護: 生体情報がネットワーク上に流れない。

攻撃の種類

攻撃手法	特徴	対象とするパスワード	攻撃方法	対策例
パスワードリスト攻撃	流出したパスワードリストを使用して攻撃する	既存の流出パスワード	アカウントと流出パスワードの組み合わせを試す	2要素認証、流出パスワードの再利用防止
辞書攻撃	よく使われる単語のリストを使用して攻撃する	単純な構造や一般的な単語を使用したパスワード	辞書に含まれる単語やフレーズを試す	複雑なパスワードの利用、辞書攻撃防止のアルゴリズム
ブルートフォース	可能なすべての組み合わせを試す攻撃	すべての種類のパスワード	文字列の全組み合わせを機械的に試す	ロックアウトポリシー、パスワード試行回数の制限
レインボー攻撃	ハッシュ値と事前計算された値を利用する攻撃	ハッシュ化されたパスワード	レインボーテーブル（事前計算値）を使用	ソルトの導入、長いパスワードの利用

リバース vs フォワード

特徴	リバースプロキシー	フォワードプロキシー
配置場所	サーバー側	クライアント側
通信の方向	クライアント → リバースプロキシー → サーバー	クライアント → フォワードプロキシー → インターネット
主な目的	サーバーの保護、負荷分散、キャッシュ	プライバシー保護、コンテンツフィルタリング
使用例	ウェブサーバーのセキュリティ強化	学校や企業でのインターネット管理
セキュリティ	サーバーのIPを隠し、不正アクセスを防止	ユーザーのIPを隠し、匿名性を確保

認証認可

SAML: 認証情報を「アサーション」という形式で渡し、エンタープライズ環境でのSSOが主な利用ケース。

OIDC: OAuth 2.0の上に構築された認証プロトコルで、ユーザー情報（IDトークン）も提供。

OAuth 2.0: リソースへのアクセス権限を付与する認可に特化。認証は行わないため、OIDCなどと組み合わせて使うことが多い。

項目	SAML	OIDC	OAuth 2.0
目的	シングルサインオン（SSO）と認証に特化	認証とID提供	認可（Authorization）のみを提供
対象ユーザー	エンタープライズ向け、主にWebアプリケーションで使用	Webアプリやモバイルアプリ向けの認証	WebアプリやAPIでのアクセス制御
データ形式	XML	JSON	JSON
通信プロトコル	SOAPやHTTP Redirect/POST	HTTP/REST	HTTP/REST
トークンの種類	Assertion（アサーション）	IDトークン	アクセストークン
使用シナリオ	大規模な組織内でのSSO	クライアント認証が必要なアプリケーション	アクセス権限の管理やAPI呼び出しの認可
セキュリティの特徴	安全性高いが実装が複雑	比較的簡単な実装で、ユーザー認証を提供	認可に特化し、認証には別途仕組みが必要
互換性	古い標準だが、広く採用されている	モダンなWebアプリやモバイルアプリに適している	さまざまなアプリケーションやAPIで利用可能
例	Shibboleth、Okta	Google、Microsoft、Facebookのログイン	APIアクセスの権限付与（Google APIなど）

JWT

{header}.{payload}.{encryption}

アルゴリズム	タイプ	特徴	セキュリティ強度	推奨度
HS256	対称暗号	秘密鍵を共有して署名を生成・検証	高い（鍵管理が重要）	中程度
RS256	非対称暗号	秘密鍵で署名、公開鍵で検証	非常に高い	高い
ES256	非対称暗号	楕円曲線暗号を使用し、効率的	非常に高い	高い
PS256	非対称暗号	RSA-PSS署名方式を使用し、より安全	非常に高い	非常に高い
None	なし	署名なし（セキュリティなし）	低い	使用禁止

罠サイトへのアクセス時の動き

これは、攻撃者のアカウントでログインして、その認可コードでアップロードさせているので、アカウントとしては、攻撃者、になる。
ん－、OAuth 実装とかしてないとピンと来ない・・ね

で、state を、以下の位置で渡して、それが同一セッションかを確認することで検知する

クラウド

CDN って？

キャッシュサーバーの利用 CDNは、オリジンサーバー（元のコンテンツが保存されているサーバー）からコンテンツを複製し、世界中に分散配置されたキャッシュサーバーに保存します。これにより、ユーザーの近くにあるキャッシュサーバーからコンテンツを配信できるため、物理的な距離を短縮し、表示速度を向上させます。
負荷分散アクセスが集中した場合でも、複数のキャッシュサーバーがリクエストを分散処理するため、オリジンサーバーの負荷を軽減し、サーバーダウンのリスクを低減します。

FQDN（Fully Qualified Domain Name）は

ホスト名.ドメイン名.トップレベルドメイン

例えば：

www.example.com（ウェブサーバーの場合）
mail.example.com（メールサーバーの場合）

FQDNには、必ず最後にドット（.）が付いているとされていますが、実際には省略されることがほとんどです。

具体的には、FQDNは次のような場面で重要です：

DNS（ドメインネームシステム）の設定。

ネットワークでのサーバーやデバイスの識別。

証明書の発行など、セキュリティ関連のプロセス。

FQDN が Host header に設定される例

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

認証

SAML by POST

User to SP

GET /login HTTP/1.1
Host: www.example-sp.com
User-Agent: Mozilla/5.0
Accept: text/html
Connection: keep-alive

認証要求 SP to IdP

POST /saml/authn HTTP/1.1
Host: www.example-idp.com
Content-Type: application/xml
Content-Length: 457

<SAMLRequest>
    <Issuer>www.example-sp.com</Issuer>
    <Destination>www.example-idp.com</Destination>
    <ID>1234567890</ID>
</SAMLRequest>

認証情報送信 user to IdP

POST /auth HTTP/1.1
Host: www.example-idp.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 45

username=exampleuser&password=securepassword

SAML Response IdP to SP

POST /saml/acs HTTP/1.1
Host: www.example-sp.com
Content-Type: application/xml
Content-Length: 867

<SAMLResponse>
    <Issuer>www.example-idp.com</Issuer>
    <Status>Success</Status>
    <Assertion>...</Assertion>
</SAMLResponse>

redirect SP to User

GET /dashboard HTTP/1.1
Host: www.example-sp.com
User-Agent: Mozilla/5.0
Accept: text/html
Connection: keep-alive

SAML by GET

REquest SP to User

GET /saml/authn?SAMLRequest=BASE64_ENCODED_REQUEST HTTP/1.1
Host: www.example-idp.com
User-Agent: Mozilla/5.0
Accept: text/html
Connection: keep-alive

認証情報送信 user to IdP

POST /auth HTTP/1.1
Host: www.example-idp.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 45

username=exampleuser&password=securepassword

SAML response IdP to SP

POST /saml/acs HTTP/1.1
Host: www.example-sp.com
Content-Type: application/xml
Content-Length: 867

<SAMLResponse>
    <Issuer>www.example-idp.com</Issuer>
    <Status>Success</Status>
    <Assertion>...</Assertion>
</SAMLResponse>

ODIC

state

役割: リクエストとレスポンスを紐付けるために使用され、クロスサイトリクエストフォージェリ（CSRF）攻撃を防ぐための重要な要素です。クライアントが認可リクエストを送信する際に、一意の値（state）を生成し、リクエストに含めます。この値は、レスポンスが戻ってきた際に一致するかを検証することで、意図しないリクエストを検出します。

request

GET /authorize?response_type=code&client_id=example-client
&redirect_uri=https://client.example.com/callback
&state=12345abcde HTTP/1.1
Host: authorization-server.example.com

response

HTTP/1.1 302 Found
Location: https://client.example.com/callback?code=xyz&state=12345abcde

攻撃者がごまかせない理由

攻撃者が利用者から認可コードを盗んだとしても、その認可コードは攻撃者のセッション情報やリクエストに基づいて返ってきたものではありません。

サービスプロバイダーは、レスポンスのstate値を元のリクエストのstate値と照合するため、攻撃者のセッション情報では一致しないことが即座に判明します。

state値はブラウザセッションごとに一意であるため、攻撃者がstate値を正確に偽装することは非常に困難です。

nonce

目的: 主にIDトークンの発行において、リプレイ攻撃（過去の通信を再利用した攻撃）を防ぐために利用されます。

使用タイミング: 認可リクエスト時に生成され、レスポンスのIDトークン内に含まれる。

具体的な役割:

認可サーバーが返すIDトークンに含まれるnonce値が、リクエスト時に送信したものと一致するかをクライアントが検証することで、トークンの正当性を確認します。

nonce は、要求ー＞認可の一致を確認するとともに、
一度使った nonce はクリアされることで、他者が再利用しようとしても使えなくなる。
この再利用が、replay 攻撃って言われるやつ

nonce の例

{
  "header": {
    "alg": "RS256",
    "typ": "JWT"
  },
  "payload": {
    "iss": "https://authorization-server.example.com",
    "aud": "example-client-id",
    "sub": "1234567890",
    "exp": 1681238167,
    "iat": 1681234567,
    "nonce": "random-nonce-abc123"
  },
  "signature": "SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"
}

nonce の例

{
  "id_token": {
    "sub": "1234567890",
    "name": "John Doe",
    "nonce": "random-nonce-abc123",
    "iat": 1681234567,
    "exp": 1681238167
  }
}

攻撃手法

ドメインフロンティング

ドメインフロンティングとは、主にCDN（コンテンツデリバリネットワーク）を悪用して、通信の監視を回避する手法です。この技術では、TLS通信のSNI（Server Name Indication）ヘッダに記載されたドメイン名と、HTTPリクエストのHostヘッダに記載されたドメイン名を異なるものに設定します。これにより、実際の通信先を隠し、攻撃者がマルウェアのC&C（Command and Control）通信を隠すために利用することが多いです

例

GET /malicious-path HTTP/1.1
Host: attackerserver.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Connection: keep-alive

Hostヘッダが偽装されると、通信の転送はサーバー側で行われるため、間にあるファイアウォール（FW）ではその内容を直接確認することができません。これは、HostヘッダがHTTPリクエストの一部であり、TLS通信の暗号化によって保護されている場合、FWがその内容を検査することが困難になるためです。

さらに、CDNの名前解決によって得られるIPアドレスをフィルタリングする場合、以下の問題が発生します：

他のサービスへの影響 CDNは複数のサービスのコンテンツをキャッシュして配信するため、特定のIPアドレスをフィルタリングすると、そのIPアドレスを利用している他の正当なサービスにも影響を及ぼします。これにより、意図しない通信遮断が発生する可能性があります。
動的なIPアドレスの変更 CDNのIPアドレスは動的に変更されることが多いため、フィルタリングルールを維持するのが困難です。これにより、フィルタリングが効果を失う可能性があります。
サービスの可用性低下 CDNを利用するサービスは、グローバルな分散型ネットワークを活用して高速なコンテンツ配信を行っています。特定のIPアドレスをフィルタリングすることで、サービスの可用性やパフォーマンスが低下するリスクがあります。

Referer in Request Header from client

Refererヘッダーは、HTTPリクエストに含まれる情報で、現在リクエストされているページにリンクしていた直前のページのURLを示します。このヘッダーは、ウェブサイト間のトラフィック分析やアクセス元の特定に役立ちます。

例

例えば、ユーザーが https://example.com/page1 からhttps://example.com/page2 に移動した場合、page2 へのリクエストには以下のようなRefererヘッダーが含まれます：

GET /page2 HTTP/1.1
Host: example.com
Referer: https://example.com/page1

Referrer-Policy in Response Header from server

ウェブサイトは Referrer-Policy ヘッダーを使用して、Refererヘッダーに含める情報の範囲を制御できます。例えば：

no-referrer: Refererヘッダーを送信しない。
origin: ドメイン部分のみを送信。
strict-origin-when-cross-origin: 同一オリジンでは完全なURLを送信し、クロスオリジンではドメイン部分のみを送信。

TLS.SNI

TLSのSNI（Server Name Indication）は、TLS（Transport Layer Security）プロトコルの拡張機能で、クライアントが接続先のサーバー名（ドメイン名）をTLSハンドシェイクの初期段階でサーバーに通知する仕組みです。これにより、1つのIPアドレスで複数のドメインをホストする場合でも、適切なSSL/TLS証明書を選択してセキュアな通信を確立できます。

Handshake Protocol: ClientHello
    Version: TLS 1.2
    Random: 5e6a7d8fc9d1ea2b3f4c5d6e7f8g9h10
    Session ID: <empty>
    Cipher Suites:
        TLS_RSA_WITH_AES_256_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    Compression Methods:
        NULL
    Extensions:
        Server Name: www.example.com
        Supported Versions: TLS 1.2, TLS 1.3
        Signature Algorithms: RSA, ECDSA
        Key Share: <key information>

Host Header

Hostヘッダは、HTTPリクエストにおいて、クライアントがアクセスしたいサーバーのホスト名とポート番号を指定するために使用されます。これにより、サーバーはどのホスト名に紐づくリソースを提供するべきかを判断できます。

主な目的は以下

リソースの識別

単一のIPアドレスで複数のホスト名（ドメイン名）を管理する場合、Hostヘッダを利用してリクエストがどのホスト宛てなのかを特定します。これにより、仮想ホスト（バーチャルホスト）機能が実現されます

通信の正確性

HTTP/1.1以降では、Hostヘッダの指定が必須となっており、欠けている場合はリクエストが正しいものとみなされず、エラー（400 Bad Request）が返されます.

負荷分散

複数のサーバーでリクエストを分散処理する際、Hostヘッダを利用して適切なサーバーにリクエストを送信できます.

セキュリティ

ホスト名に基づいてアクセス制御を行うことで、不正アクセスを防止する役割も果たします.

防御策

これらの対策を組み合わせることで、ドメインフロンティングによるリスクを大幅に軽減できます。さらに詳しい情報が必要であれば、こちらやこちらを参考にしてください。

SNIフィルタリングの実施

TLS通信のSNI（Server Name Indication）フィールドとHTTPリクエストのHostヘッダの不一致を検出する仕組みを導入します。これにより、不正な通信を早期に特定できます。

CDNプロバイダとの連携

CDNプロバイダに協力を仰ぎ、不正なドメインフロンティングを検知する体制を構築します。特定のSNIリクエストに対して警告を発する設定や異常通信の監視を強化することが効果的です。

プロキシサーバーの利用

~~プロキシサーバーを導入し、HTTPリクエストのHostヘッダとURL内のドメインが一致しているかを確認することで、不正な通信を防ぎます。~~

browser に入力した URL = Request Header.Host である為、この確認はできない。

脆弱性の更新と修正

使用しているサーバーやデバイス、ツールを常に最新の状態に保ち、セキュリティパッチを適用することで、攻撃のリスクを低減します。

セキュリティプログラムの導入

マルウェアや不正な通信を検出できるウイルス対策ソフトやファイアウォールを活用し、ネットワーク上の不正な接続を防ぎます。

browser への URL 入力と、Host の関係

ブラウザのアドレスバーにURLを記入した場合、以下の流れでHostヘッダが設定されます：

ブラウザの動作

ユーザーがURLを入力例えば、https://www.example.com/index.htmlを入力するとします。
DNS解決ブラウザは入力されたドメイン名（www.example.com）をDNSサーバーに問い合わせ、対応するIPアドレスを取得します。
HTTPリクエストの生成ブラウザは以下のようなHTTPリクエストを生成します：
```
GET /index.html HTTP/1.1
Host: www.example.com
```
- Hostヘッダには、ユーザーが入力したドメイン名が設定されます。
- HTTPSの場合、ポート番号443が暗黙的に使用されますが、明示的に指定することも可能です（例：Host: www.example.com:443）
サーバーへの送信リクエストがサーバーに送信され、Hostヘッダを基に適切なリソース（/index.html）が提供されます。

ブラウザの動作 2

ユーザーがブラウザに以下のURLを入力した場合：

https://www.example.com/about.html

生成されるHTTPリクエストは以下のようになります：

GET /about.html HTTP/1.1
Host: www.example.com

サーバーの動作

サーバーはHostヘッダを確認し、www.example.comに関連するリソース（/about.html）を返します。

仮想ホストの利用例

もしサーバーが複数のドメインをホストしている場合、Hostヘッダを基にリクエストを振り分けます：

Host: www.example.com → /var/www/example

Host: www.anotherexample.com → /var/www/anotherexample

これにより、ブラウザのアドレスバーに入力されたURLが正確に処理され、適切なリソースが提供されます。

PKI（公開鍵基盤）についての詳細まとめ

PKI全体像

概要: 公開鍵暗号方式を活用し、ネットワーク通信の安全性を保証する仕組み。
詳細: デジタル証明書や暗号化プロトコルにより機密性、認証性、改ざん防止を実現。
具体例: HTTPS通信、VPN接続、電子署名。

デジタル証明書

概要: 公開鍵と所有者を結びつける電子文書。
詳細: 証明書には発行者情報、所有者情報、公開鍵、有効期限、デジタル署名が含まれる。
具体例: ウェブサイト認証用のSSL/TLS証明書、電子メール暗号化用の証明書。

CA（Certificate Authority）、RA（Registration Authority）、IA（Issuing Authority）

CA:
- 概要: 信頼の基盤となるデジタル証明書を発行する機関。
- 詳細: 信頼性を保証し、証明書の発行・失効を管理。
- 具体例: GlobalSign、DigiCert、Let's Encrypt。
RA:
- 概要: 証明書発行前の身元確認を行う。
- 詳細: CAと連携して利用者の情報を確認。
- 具体例: 大規模企業での運用。
IA:
- 概要: 証明書発行を担当するシステムや部門。
- 詳細: 発行手続き全般を管理。
- 具体例: CA内の技術部署。

一連の手順、CSR(Certificate Signing Request)、CP(Certificate Policy)・CPS(Certification Practice Statement)

一連の手順:
1. 公開鍵生成とCSR（証明書署名要求）の作成。
2. CSRをCAに提出し、身元確認を受ける。
3. CAがデジタル証明書を発行。
CSR:
- 概要: 証明書発行のリクエスト情報。
- 詳細: 公開鍵や所有者情報、署名を含む。
- 具体例: PEM形式のリクエストファイル。
CP・CPS:
- CP: 証明書発行の方針を記述した文書。
- CPS: CPに基づく具体的な運用手順を定めた文書。

デジタル証明書のチェック方法

概要: 証明書の信頼性や有効性を確認する手順。
詳細:
- 有効期限の確認。
- CRL（証明書失効リスト）またはOCSP（Online Certificate Status Protocol）の利用。
- 証明書チェーン（ルートCA～リーフ証明書）の整合性チェック。
具体例: ブラウザでの証明書詳細表示を確認。

常時SSL化と通信内容の検査

常時SSL化:
- 概要: ウェブサイト全体をHTTPS対応とする。
- 詳細: 暗号化通信で安全性を向上。
- 具体例: HTTPSにリダイレクト設定。
通信内容の検査:
- 概要: TLSハンドシェイクで鍵交換を検証。
- 詳細: DPI（ディープパケットインスペクション）を活用したデータ分析。
- 具体例: セキュリティアプライアンスによる通信のモニタリング。

TLS（Transport Layer Security）

概要: ネットワーク通信を暗号化するプロトコル。
詳細:
- TLS 1.2: 現在広く利用されている。
- TLS 1.3: パフォーマンスとセキュリティを強化。
具体例: クライアントHelloとサーバーHelloで鍵交換を開始。

HSTS（HTTP Strict Transport Security）

概要: HTTPS接続を強制し、HTTP通信を防ぐ仕組み。
詳細:
- サーバーが「Strict-Transport-Security」ヘッダーを送信。
- HTTPダウングレード攻撃を予防。
具体例: Strict-Transport-Security: max-age=31536000; includeSubDomains。

デジタル証明書の利用

概要: デジタル証明書を活用して通信やシステムの安全性を向上。
詳細:
- ウェブサイト認証（HTTPS）。
- Eメール暗号化・署名（S/MIME）。
- ソフトウェアの信頼性保証（コード署名）。
具体例: SSL証明書によるウェブ通信の暗号化。

時刻認証

概要: 通信やデータの正確なタイムスタンプを付与して時間的な信頼性を保証。
詳細:
- デジタル署名やタイムスタンプ技術を活用。
- 時刻同期による整合性確認。
具体例: 電子契約でのタイムスタンプ付与。

証明書レベル

種類	概要	検証プロセス	利用例	特徴
DV Domain Validation	ドメイン所有者の認証を行う最も簡易的な証明書。	ドメイン所有権の確認（DNSレコードやメール確認）。	個人ブログ、非商業サイト。	発行が迅速で安価。
OV Organization Validation	ドメインに加え組織情報を確認する中程度の信頼性を持つ証明書。	組織の正式な登記情報や電話番号を確認。	商業サイト、企業ウェブサイト。	サイト訪問者に組織の信頼性を示す。
EV Extended Validation	最も厳格な検証プロセスを経た高信頼性の証明書。	組織の詳細情報、財務記録、法的存在を徹底的に確認。	金融サイト、Eコマースサイト。	アドレスバーが緑色になり信頼性向上。

SSLおよびTLSバージョンの比較

バージョン	概要	セキュリティ	特徴	サポート状況
SSL 3.0	初期の暗号化プロトコルで広く使用された	脆弱性が多い	安全性が低く、現在は非推奨。	廃止済み
TLS 1.0	SSL 3.0の後継。基本的な暗号化機能を提供	脆弱性が発見されている	改善された暗号化方式を採用するが現在は非推奨。	廃止済み
TLS 1.1	TLS 1.0の改良版	旧式化している	改善された暗号化方式とセキュリティ機能が追加。	廃止済み
TLS 1.2	広く使われている標準プロトコル	高いセキュリティレベル	ハンドシェイクの柔軟性が向上し、多くのアルゴリズムをサポート。	現在も使用可能
TLS 1.3	最新の暗号化プロトコル	非常に高いセキュリティレベル	ハンドシェイク回数を削減し、効率性と安全性を両立。	現在の推奨バージョン

1. セキュリティの向上

暗号スイートの簡素化: TLS 1.2では、多数の暗号スイート（アルゴリズムの組み合わせ）がありましたが、一部が脆弱性の原因となりました。TLS 1.3では、古い暗号スイート（例: RSA鍵交換、静的Diffie-Hellman）を廃止し、より安全なアルゴリズム（例: ECDHE鍵交換）に限定されています。

フォワードセキュリティ: TLS 1.3では、すべての鍵交換にフォワードセキュリティ（鍵が漏洩しても過去の通信内容は解読されない）が標準的に適用されます。

2. パフォーマンスの向上

ハンドシェイクの効率化: TLS 1.2ではハンドシェイクに複数回の往復通信が必要でしたが、TLS 1.3ではハンドシェイクが1往復で完了するように最適化されています。これにより、通信の初期遅延が大幅に改善されます。

早期データ送信（0-RTT）: TLS 1.3では、以前に接続したことのあるクライアントが、セッション再開時に0-RTT（ラウンドトリップタイム0）でデータを送信できます。これにより、再接続が非常に高速になります。

3. 暗号化方式の変更

暗号アルゴリズムの削除: TLS 1.3では、安全性の低いアルゴリズム（例: SHA-1やRC4）が廃止されました。これにより、暗号化の強度が向上しています。

AEAD暗号の採用: TLS 1.3では、暗号化方式としてAEAD（Authenticated Encryption with Associated Data）モードが必須となり、データの整合性と機密性が同時に保証されます。

4. プロトコルの変更

セッションIDとセッションチケットの見直し: TLS 1.2ではセッションIDとセッションチケットを使用してセッションを再開していましたが、TLS 1.3ではこれがより安全に再設計されています。

非同期動作: TLS 1.3は、プロトコル全体が非同期に対応し、柔軟性が向上しました。

具体例を交えたポイント

TLS 1.2と1.3の主な違い

特徴	TLS 1.2	TLS 1.3
鍵交換方式	RSA, Diffie-Hellmanなど	ECDHEのみ
ハンドシェイク回数	2往復以上	1往復
暗号スイート	多数（RSAやSHA-1など含む）	限定的で安全性が高い（AEAD必須）
データ送信開始	セッション完了後	0-RTT（0 Round Trip Time)対応
削除された技術	弱いアルゴリズムやプロトコルを一部残している	不要な技術を廃止、簡素化

リプレイ攻撃防止のための策

Nonce（ナンス）
概要: リプレイ攻撃（過去の通信を再利用した攻撃）を防ぐため、一意のランダムな値を生成して使用します。

クライアント側がリクエストにnonceを付加。

サーバー側はそのnonceを記録し、再利用されていないかをチェックします。

課題: 非常に短期間しか有効でないため、短時間で大量のリクエストを処理する場合、管理が複雑になります。

Salt（ソルト）
概要: 固定値を追加して、ハッシュ値や暗号の計算に組み込む技術。

nonceが一度限りの値であるのに対し、saltは繰り返し利用する場面でも効果的に動作します。

利用例: データのハッシュ化処理やパスワード強化。

リプレイ攻撃への対応: nonceと組み合わせて一意性をさらに強化可能です。

Pepper（ペッパー）
概要: Saltに似ていますが、サーバーが秘密に保持するランダムな値。

Saltと異なり、外部に公開されない特徴があります。

利用例: 機密性が高い認証情報の処理時に追加の保護を提供。

リプレイ攻撃への対応: Pepperがリプレイ攻撃の成功を大幅に困難にします。

サーバーサイドのリプレイ検知
概要: サーバーが受信したリクエストの時間を記録し、過去のデータとの比較でリプレイ攻撃を検知。

実装方法:

タイムスタンプ検証: リクエストが許容範囲内の時間（例: 数秒間）に送信されたか確認。

セッションの再利用禁止: セッションチケットが既に使用されていれば拒否。

セキュリティ強化のための推奨事項
TLS 1.3の仕様活用: 0-RTTにおけるリプレイ攻撃を避けるために、サーバーが0-RTTデータを特別に取り扱う設計が推奨されます（例: 特定の操作には0-RTTを許可しないなど）。

クライアントサイドの協力: クライアントが送信するリクエストに署名付きメッセージを付加することで、攻撃者による改ざんを難しくします。

RFC9162: Certificate Transparency

ファイヤーウォール

大枠

項目	IDS: Intrusion Detection System (侵入検知システム)	IPS: Intrusion Prevention System (侵入防止システム)	UTM: Unified Threat Management (統合脅威管理)
目的	ネットワークやシステム内での脅威を検知する	脅威を検知し、それを未然に防ぐ	複数のセキュリティ機能を統合し、包括的な防御を提供
機能	ログ監視、異常検知、アラート送信	脅威の検知・ブロック、トラフィック制御	ファイアウォール、IPS、ウイルス対策、Webフィルタリングなど
リアルタイム対応	対応なし（検知のみ）	対応あり（ブロック・防御機能）	対応あり（多機能で包括的な対応）
管理の複雑さ	中程度	高い	非常に高い
導入コスト	比較的低い	IDSより高い	IPSよりさらに高い
適用範囲	ネットワークまたはホスト単位	ネットワークまたはホスト単位	全社的なセキュリティ管理に適用
主な利用者	中小企業、特定用途のセキュリティが必要な環境	大企業、リアルタイム防御が必要な環境	セキュリティ管理を一元化したい組織
主な特徴	パッシブ（検知のみ）、ログや監査に有用	アクティブ（防御も行う）、システム負荷が高い可能性	オールインワン、統合管理が可能

ファイヤーウォール比較

ファイアウォールの種類	特徴	メリット	デメリット
パケットフィルタリング型	パケットヘッダ情報（IPアドレスやポート番号など）を基に通信を制御	動作が高速、シンプル	アプリケーション層の攻撃を防御できない
ステートフルインスペクション型	通信の状態（セッション情報）を考慮してパケットをフィルタリング	より高いセキュリティレベルを提供	システム負荷が増加
プロキシ型	通信を一旦代理（プロキシ）で受けてから転送する	アプリケーション層の詳細なチェックが可能	通信遅延が発生する可能性がある
L7FW（Layer 7 Firewall）	アプリケーション層（HTTP/HTTPSなど）の内容を解析して通信を制御	高度な攻撃防御が可能（例：SQLインジェクションなど）	コストが高い、導入・運用が複雑
UTM（統合脅威管理）	複数のセキュリティ機能（ファイアウォール、IPS/IDSなど）を統合	一元管理による運用効率向上	高価であり、システム負荷が高い
次世代型ファイアウォール（NGFW）	ステートフルインスペクションに加え、アプリケーションやユーザの制御機能	高度なセキュリティ機能を提供	コストが高く、複雑な設定が必要

OSI 7

層名 (階層番号)	主な役割	主なプロトコル・技術	具体例
アプリケーション層 (第7層)	ユーザーと直接やりとりするインターフェース	HTTP, FTP, SMTP, DNS	Webブラウザ、メールクライアント、ファイル転送アプリ
プレゼンテーション層 (第6層)	データの形式変換、暗号化や圧縮	TLS, SSL, JPEG, MPEG	データ暗号化（HTTPS通信）、画像/動画フォーマット変換
セッション層 (第5層)	通信セッションの確立、管理、終了	NetBIOS, PPTP	ログインセッションの維持、接続の再開
トランスポート層 (第4層)	エラー検出や再送制御、信頼性の確保	TCP, UDP	TCP（データの信頼性確保）、UDP（リアルタイム通信での利用例：ビデオ通話、オンラインゲーム）
ネットワーク層 (第3層)	ルーティングやIPアドレスの割り当て	IP, ICMP, OSPF, BGP	ルータによるパケット転送、Pingコマンド
データリンク層 (第2層)	隣接する機器間でのデータ転送	Ethernet, PPP, Wi-Fi, EAP, RADIUS	スイッチング、MACアドレスを使用した通信、無線LAN認証
物理層 (第1層)	電気信号や光信号としてのデータ伝送	USB, Bluetooth, 光ファイバー, 電気信号	ケーブル接続、光通信、無線通信

補足

RADIUS（Remote Authentication Dial-In User Service）がデータリンク層に含まれている理由についてですが、これは少し誤解を招く可能性があります。RADIUS自体は、主にアプリケーション層（第7層）で動作するプロトコルです。RADIUSは、認証、認可、アカウンティング（AAA）を提供するために設計されており、ネットワーク上の認証サーバーと通信する役割を果たします。

一方で、EAP（Extensible Authentication Protocol）はデータリンク層（第2層）で動作するプロトコルであり、RADIUSと密接に連携して動作します。具体的には、EAPは認証フレームワークとして機能し、RADIUSはそのEAPメッセージをカプセル化して認証サーバーに送信します。このため、RADIUSがEAPと関連付けられてデータリンク層に記載されることがありますが、厳密にはRADIUSはアプリケーション層のプロトコルです。

ファイヤーウォール

ファイアウォールの種類	特徴	対応するOSI階層
パケットフィルタリング型	パケットのヘッダ情報(IPアドレスやポート番号)を基に通信を制御	第3層 (ネットワーク層)
パケットフィルタリング型	動作が高速でシンプル	第4層 (トランスポート層)
ステートフルインスペクション型	通信のセッション情報を利用してパケットをフィルタリング	第3層 (ネットワーク層)
ステートフルインスペクション型	信頼性向上のためのセッション管理	第4層 (トランスポート層)
プロキシ型	通信を代理で受け取って内容をチェック	第7層 (アプリケーション層)
L7FW (Layer 7 Firewall)	アプリケーション層のデータを解析して高度な制御	第7層 (アプリケーション層)
UTM (統合脅威管理)	複数階層を統合管理し包括的なセキュリティ対策を提供	第3層～第7層
次世代型ファイアウォール (NGFW)	ステートフルインスペクション+アプリケーション識別やユーザー識別機能	第3層～第7層

SSH Agent Forward

SSH Agent Forwardは、リモートサーバー上でSSH認証を行う際に、ローカルマシンに保存された秘密鍵をリモートサーバーにコピーすることなく、リモートサーバー経由でSSH認証を行える仕組みです。この方法では、秘密鍵の安全性を維持しつつ、複数のサーバー間の操作を簡略化することが可能です。

サーバー

脆弱性等

用語	概要	防御策
Same-Origin Policy	同一オリジン（ドメイン、プロトコル、ポート）でのみリソースを共有可能とするブラウザの制約	- CORSで適切に許可を設定 - 不要なオリジンへのアクセスを許可しない
CORS (Cross-Origin Resource Sharing)	異なるオリジン間でリソース共有を可能にする仕組み	- 安全なオリジンを明示的に指定 - デフォルトでは許可を最小限に
XSS (Cross-Site Scripting)	悪意のあるスクリプトをウェブページ上で実行させる攻撃	- 入力値のエスケープ処理 - CSP（Content Security Policy）の導入
CSRF (Cross-Site Request Forgery)	ユーザーが意図しないリクエストを強制的に送信させる攻撃	- CSRFトークンの利用 - Refererチェック
Clickjacking	隠されたフレームや透明なレイヤーを用いてユーザーを誤誘導する攻撃	- X-Frame-Optionsヘッダー設定 - フレームバスティングの実装
SSRF (Server-Side Request Forgery)	攻撃者がサーバーを介して内部リソースへのリクエストを送信させる攻撃	- 外部からのリクエストを制限 - フィルタリングで不正なURLをブロック
MITM (Man-In-The-Middle)	通信の途中に入り込んでデータを盗聴・改ざんする攻撃	- HTTPS/TLSの導入 - HSTSの活用
RCE (Remote Code Execution)	攻撃者がサーバー上で任意のコードを実行する攻撃	- 入力検証の強化 - アプリケーションの更新とパッチ適用
SQL Injection	攻撃者が悪意のあるSQLコードをデータベースに挿入し実行させる攻撃	- パラメータ化されたクエリを使用 - データベースへの直接アクセスを制限
Path Traversal	ファイルのパスを操作して機密データを取得する攻撃	- 入力値の正規化 - 特定のディレクトリにアクセスを制限
DoS/DDoS (Denial of Service)	サーバーに過剰なリクエストを送信し正常なサービスを妨害する攻撃	- WAF（Web Application Firewall）の導入 - トラフィック監視
Brute Force Attack	パスワードや鍵を総当たりで試行する攻撃	- ロックアウトポリシーの設定 - 複雑なパスワードの使用
DNS Spoofing	偽のDNS応答を返してユーザーを悪意のあるサイトへ誘導する攻撃	- DNSSEC（DNS Security

##　DNS

攻撃手法	説明	対策
DNSキャッシュポイズニング	偽のDNS情報をキャッシュに挿入し、ユーザーを悪意のあるサイトに誘導する攻撃	- DNSSECを導入 - キャッシュの定期的なクリア
DNSアンプ攻撃	DNSサーバーを利用して大量のトラフィックを生成し、ターゲットを攻撃する	- DNSサーバーの設定を厳密化 - レート制限を適用
DNSトンネリング	DNSクエリを利用してデータを隠し、悪意のある通信を行う攻撃	- DNSクエリの監視とフィルタリング - 不審なトラフィックの検出
ドメインハイジャック	ドメインの登録情報を変更し、攻撃者が制御するサイトに誘導する攻撃	- WHOIS情報の保護 - 強力な認証と監視
サブドメインテイクオーバー	未使用のサブドメインを利用して攻撃者が悪意のあるコンテンツをホストする。 CNAME: 未使用のターゲットドメインが存在することで攻撃者が新しいサービスを利用して悪用 A: 指定されたIPアドレスが管理されていない場合に同様の乗っ取りが起こるリスク	- サブドメインの管理を徹底 - DNS設定の定期的な確認
DNSリフレクション攻撃	DNSサーバーを利用してターゲットに大量の応答を送信する攻撃	- DNSサーバーの設定を厳密化 - レート制限を適用
DNSスプーフィング	偽のDNS応答を返してユーザーを悪意のあるサイトに誘導する攻撃	- DNSSECを導入 - DNSクエリの検証
ドメインフロンティング Domain Fronting	正規のドメインを偽装して悪意のある通信を行う攻撃	- TLSのSNIフィルタリング - 不審なドメインの監視
DNSリソース枯渇攻撃	DNSサーバーのリソースを使い果たしてサービスを停止させる攻撃	- サーバーのリソース監視 - レート制限と負荷分散

FQDN: Fully Qualified Domain Name

URL (URI) 
https://www.example.co.jp:8080/example/index.htm?page=...
~~~~~ スキーム
        ~~~ ホスト名　　　　　　　　　　||FQDN = host + domain: www.example.co.jp
            ~~~~~~~~~~~~ ドメイン名    |
            　　　　　　　 ~~~~ ポート
                            　　~~~~~~~~~~~~~~~~~ パス
                                                 ?~~~~~~ クエリ

DHCP

項目	リミテッドブロードキャスト	通常のブロードキャスト
アドレス形式	`255.255.255.255`	例: `192.168.1.255`
通信範囲	ローカルネットワーク全体	同一ネットワークセグメント内
ルーターの挙動	ルーターを越えて転送しない	通常、ルーターは転送しない
主な用途	DHCPリクエスト、初期設定	ARP、ネットワークデバイス検出

クリックジャッキング対策

対策	説明
X-Frame-Options ヘッダー設定	ページがフレーム内にロードされることを制御する。例: `DENY`, `SAMEORIGIN`, `ALLOW-FROM` を指定。
Content Security Policy (CSP)	`frame-ancestors` ディレクティブを使用して許可されたフレーム埋め込み元を制限する。
フレームバスティング	JavaScriptを使用して、ページがフレーム内でロードされないように検出し、トップレベルウィンドウにリダイレクトする。
HTTPS 使用	セキュアな通信を確保することで、攻撃者による悪意あるスクリプト挿入を防止する。
UI デザインの工夫	ボタンやリンクの位置を慎重に配置し、透明なレイヤーや不正な操作を防止する。

Same-Origin Policy
意味: 同一のオリジン（ドメイン、プロトコル、ポート）間でのみリソース共有を許可するウェブブラウザのセキュリティ制約です。

役割: 異なるオリジン間でのデータアクセスや操作を制限し、XSSやCSRFなどの攻撃を防ぐ仕組みです。

X-Frame-Options: sameorigin
意味: HTTPヘッダーで指定されるオプションで、ページがフレーム内でロードされる場合に同じオリジンでのフレーム埋め込みを許可します。

役割: クリックジャッキング防止のために使用され、外部オリジンからのフレーム埋め込みをブロックします。

mail

方式	概要	特徴	目的
SPF	送信ドメインのIPアドレスを指定して認証する仕組み。	DNSレコードに許可されたIPアドレスを登録し、受信側は送信元が正規のサーバーか確認可能。	なりすましメールの防止
DKIM	電子署名を使用して、メール本文の整合性と送信元ドメインを認証する仕組み。	送信メールに署名を付与し、受信側は公開鍵で署名の正当性と改ざんがないことを検証。	メール改ざんやなりすましメールの防止
DMARC	SPFやDKIMを基に、メールの認証結果をポリシーに従って制御する仕組み。	SPF/DKIMの結果を統合し、ポリシーを設定可能（例: 拒否、隔離、受け入れ）。	ドメイン管理者が認証失敗時の処理を明確に定義
BIMI	DMARCを利用してブランドロゴを認証されたメールに表示する仕組み。	DMARC認証成功後、認証されたブランドロゴが表示されることで信頼性向上。	ブランド信頼性の向上と視覚的認知の強化

spf 検証不可

パターン	原因	対応策
SPFレコード未設定	ドメインにSPFレコードが存在しないため、正規の送信元を判定できない。	DNSにSPFレコードを設定し、正しい送信元を指定する。
SPFレコードの構文エラー	SPFレコードに記述ミス（例: スペースや記号の誤り）がある場合。	SPFレコードの構文をチェックツールで検証し、修正する。
DNSクエリ制限の超過	SPFチェック中にDNSクエリの回数が多すぎて制限に引っかかる。	SPFレコード内の`include`を最適化し、DNSクエリ回数を減らす。
送信元IPがSPFレコードに未登録	送信サーバーのIPアドレスがSPFレコードに含まれていない。	SPFレコードに該当するIPアドレスを追加登録する。
誤ったポリシー設定	SPFレコードに`-all`を使用して誤った拒否ポリシーを設定している場合。	必要に応じて`~all`（ソフトフェイル）または`+all`に変更する。
DNSプロパゲーションの遅延	SPFレコード変更後にDNSが更新されていない場合。	DNS更新を待つか、変更を正しく伝播しているか確認する。
受信側のSPF認証対応不足	受信メールサーバーがSPF認証をサポートしていない場合。	受信側のサーバー設定を確認し、SPF認証が有効か確認する。
複数SPFレコードの存在	同じドメインに複数のSPFレコードがあると正しく認証できない。	SPFレコードを一つに統合し、整理する。
DMARCポリシーの影響	DMARCのポリシーにより、SPF失敗がさらに厳格に扱われる。	DMARCポリシーを見直し、SPF検証結果と整合性を保つよう調整する。

転送すると無理

SPFの仕組みでは、検証対象となるのはメールを送信したサーバーのIPアドレスです。このIPアドレスは転送メールサーバーのものになり、元の送信ドメイン（Original送信元）のSPFレコードに含まれていない場合、SPF検証は失敗します。

流れのまとめ
元の送信者からメールが送信:

SPF認証では、元の送信ドメインのSPFレコードを参照し、元の送信サーバーのIPが正当かどうかを検証。

転送メールサーバーで再送信:

転送サーバーが新たな送信者となるが、SPFでは依然として元の送信ドメインが基準となる。

SPF検証の失敗:

転送サーバーのIPアドレスが元の送信ドメインのSPFレコードに含まれていないため、認証が失敗。

セキュアプログラミング

CSP: Content Security Policy

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-scripts.com; img-src 'self' data:;

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src 'self' https://images.com;">

主なディレクティブ

default-src: デフォルトのリソース取得元を指定。

script-src: JavaScriptの取得元を指定。

style-src: CSSの取得元を指定。

img-src: 画像の取得元を指定。

frame-ancestors: フレーム内での埋め込みを許可するオリジンを指定。

DEP

データ実行防止（DEP）は、メモリ内の特定の領域を「実行不可能」としてマークし、悪意のあるコードがその領域から実行されるのを防ぐセキュリティ機能です。具体的には、以下のような領域が対象となります

データ専用のメモリ領域: 通常、データを保持するためだけに使用されるメモリ領域で、コードの実行は許可されません。

NXビットをサポートするハードウェア: NXビット（No eXecuteビット）が有効なプロセッサでは、特定のメモリページが実行不可能としてマークされます。

ソフトウェアDEP: ハードウェアサポートがない場合でも、構造化例外処理（SafeSEH）を利用して一部の攻撃を防ぐことが可能です。

DEPは、バッファオーバーフロー攻撃やその他のメモリを悪用する攻撃を防ぐ効果があります。ただし、JITコンパイラのように実行時にコードを生成する必要がある場合には、実行可能領域として特別に設定する必要があります.

Automatic Fortification（自動強化）

元の関数	変換後の関数	説明
`strcpy`	`strncpy`	バッファオーバーフローを防ぐために、コピーする文字数を指定可能にする。
`sprintf`	`snprintf`	出力バッファのサイズを指定してオーバーフローを防止。
`gets`	`fgets`	入力サイズを制限してバッファオーバーフローを防止。
`strcat`	`strncat`	連結する文字数を指定してオーバーフローを防止。
`memcpy`	`memmove`	メモリ領域が重複する場合でも安全にコピー可能。
`scanf`	`fscanf` / `sscanf`	入力サイズを制限して安全性を向上。
`open`	`openat`	ディレクトリトラバーサル攻撃を防ぐために、相対パスを制御可能にする。
`read`	`pread`	ファイルの読み取り位置を明示的に指定して安全性を向上。
`write`	`pwrite`	ファイルの書き込み位置を明示的に指定して安全性を向上。

攻撃

XSS

XSSの種類

反射型XSS（Reflected XSS）:

攻撃者がスクリプトを含むURLを作成し、被害者にクリックさせます。

被害者がリンクをクリックすると、スクリプトが実行され、クッキー情報の漏洩や偽のページ表示が行われます。

持続型XSS（Stored XSS）:

攻撃者が悪意のあるスクリプトをウェブアプリケーションのデータベースに保存します。

被害者がそのデータを表示するページにアクセスすると、スクリプトが実行されます。

DOMベースXSS（DOM-based XSS）:

クライアントサイドでDOM操作を通じてスクリプトが実行されます。

サーバーとの通信が発生しないため、従来の防御策では防ぎにくい特徴があります。

攻撃の仕組み

攻撃者は、メールやSNSを通じて罠のリンクを送信します。

被害者がリンクをクリックすると、悪意のあるスクリプトがブラウザ上で実行されます。

これにより、クッキー情報の漏洩、セッションの乗っ取り、または偽のページへのリダイレクトが行われます。

対策

入力値のエスケープ処理: 特殊文字（例: <, >）を無害化します。

Content Security Policy (CSP): 信頼できるスクリプトのみを許可します。

WAF（Web Application Firewall）の導入: 攻撃を検知・防御します。

最新のソフトウェアを使用: 脆弱性を修正したバージョンを利用します。

SSRF

アクセスコントロール

DAC（Discretionary Access Control）、MAC（Mandatory Access Control）、RBAC（Role-Based Access Control）、SELinux を比較した表

項目	DAC	MAC	RBAC	SELinux
概要	ユーザー主体のアクセス制御	セキュリティポリシーに基づく厳密なアクセス制御	ユーザーの役割に基づくアクセス制御	MAC を実装した Linux セキュリティモジュール
制御主体	ファイル所有者やリソースの管理者	システム（セキュリティポリシーによる）	システム管理者（ユーザー役割設定）	セキュリティポリシーに基づきカーネルが制御
柔軟性	高い	低い（厳格な制御）	中程度（役割による設定が柔軟）	MAC に基づくため柔軟性は制限される
適用範囲	個別リソースのアクセス権	システム全体のアクセス制御	組織やシステム全体での役割管理	Linux システム全体
主な特徴	- ユーザーが制御 - ルートユーザーは制約なし	- 厳格で統一された制御 - すべてのユーザーに適用	- ロール（役割）に基づく - 権限の分離が容易	- セキュリティラベルによる制御 - Type Enforcement など
利点	シンプルで分かりやすい	セキュリティレベルが非常に高い	複雑な組織やシステムに対応可能	Linux システムのセキュリティ強化
欠点	誤った設定によるセキュリティリスク	設定の柔軟性に欠ける	ロールの設計や管理が複雑	設定が複雑で管理に知識が必要
例	ファイルの所有権やアクセス権設定	国家機関や軍事システム	大企業のシステム管理	Red Hat Enterprise Linux、CentOS などに採用

chmod

設定	フォルダ	ファイル
777	- 全ユーザーが読み取り、書き込み、実行可能 - フォルダ内のファイルやフォルダにアクセス可能	- 全ユーザーが読み取り、書き込み、実行可能 - 実行可能なスクリプトとして動作する可能性
666	- 全ユーザーが読み取り、書き込み可能 - 実行権限はなし - フォルダ自体にアクセス制限	- 全ユーザーが読み取り、書き込み可能 - 実行権限はなし

次のrwx: 同じグループに属するユーザーの権限。
最後のrwx: その他の全てのユーザーの権限。
それぞれの文字は以下を指します：

r (read): フォルダ自体の読み取りは可能ですが、中身は見られない。
w (write): 書き込み権限。
x (execute): フォルダ内のファイルやディレクトリへのアクセスや一覧表示が可能。

FTP

FTPのコネクション

コネクションタイプ	役割	ポート番号	特徴
制御コネクション	コマンドや認証情報の送受信	TCPポート21	クライアントとサーバー間でコマンドをやり取りするために使用されます。
データコネクション	実際のファイル転送	TCPポート20（アクティブモード）またはランダムポート（パッシブモード）	ファイルのアップロードやダウンロードを行うために使用されます。

port

よく使われるポート番号一覧

ポート番号	プロトコル	用途
20	TCP	FTPデータ転送
21	TCP	FTP制御
22	TCP	SSH（セキュアシェル）
25	TCP	SMTP（メール送信）
53	UDP	DNS（名前解決）
80	TCP	HTTP（ウェブ通信）
8080	TCP	代替HTTP（ウェブ通信）
110	TCP	POP3（メール受信）
123	UDP	NTP（時刻同期）
143	TCP	IMAP4（メール受信）
443	TCP	HTTPS（セキュアなウェブ通信）
587	TCP	SMTPサブミッションポート（メール送信の副チャンネル）
3306	TCP	MySQL（データベース接続）
5432	TCP	PostgreSQL（データベース接続）
1433	TCP	Microsoft SQL Server（データベース接続）
1521	TCP	Oracle Database（データベース接続）
27017	TCP	MongoDB（データベース接続）

SNMP

SNMPの詳細

項目	説明
プロトコル名	SNMP（Simple Network Management Protocol）
主な用途	ネットワーク機器やハードウェアの監視と管理
構成要素	SNMPマネージャ、SNMPエージェント、MIB（管理情報ベース）
通信ポート	UDP 161（ポーリング）、UDP 162（トラップ/インフォーム）
監視方法	ポーリング（定期的な情報取得）、トラップ（イベント通知）
バージョン	SNMPv1、SNMPv2c、SNMPv3（暗号化と認証機能を強化）
MIB（管理情報ベース）	管理対象オブジェクトの階層構造を定義し、OID（オブジェクト識別子）で管理
主な機能	SNMPGet（情報取得）、SNMPSet（設定変更）、SNMPTrap（通知）
セキュリティ	SNMPv3で暗号化と認証をサポート
使用例	CPU使用率、メモリ状態、ネットワークインターフェースの監視

wget とは

wget https://example.com/sample-file.zip

wgetを使用した場合、HTTPリクエストの一種であるGETメソッドを用いて対象のURLからデータを取得します。このとき、ブラウザがGETリクエストを送るのと同様に、wgetはサーバーに対してGETリクエストを送信してデータをダウンロードします。

GET /sample-file.zip HTTP/1.1
Host: example.com
User-Agent: Wget/1.x.x

LDAP Lightweight Directory Access Protocol

WAF では、LDAP の通信制御は出来ない

WAF（Web Application Firewall）は主にHTTP/HTTPS通信を対象としたセキュリティ対策ツールです。そのため、LDAP通信のようなHTTP/HTTPS以外のプロトコルを直接制御することは一般的にはできません。

リクエストの仕組み

クライアントからの接続:

LDAPクライアントは、TCP/IPを介してLDAPサーバーに接続します。

通常、ポート番号389（セキュア通信の場合は636）を使用します。

操作の種類:

クライアントは、検索（Search）、追加（Add）、削除（Delete）、変更（Modify）などの操作をリクエストします。

リクエストはASN.1（Abstract Syntax Notation One）形式でエンコードされ、LDAPメッセージとして送信されます。

レスポンスの仕組み

サーバーの処理:

LDAPサーバーはリクエストを受け取り、ディレクトリ内のデータを検索または操作します。

必要に応じて認証やアクセス制御を行います。

結果の返却:

サーバーは、操作結果をレスポンスメッセージとしてクライアントに返します。

成功した場合は成功コード、失敗した場合はエラーコードが含まれます。

Web Authentication

中間者攻撃（Man-in-the-Middle Attack）を防ぐための強力な仕組みを提供しま

1. 公開鍵暗号方式の利用

WebAuthnは公開鍵暗号方式を採用しています。認証プロセスでは、ユーザーのデバイスに保存された秘密鍵を使用して署名を生成し、サーバーには対応する公開鍵のみが保存されます。この仕組みにより、以下が可能になります：

秘密鍵はデバイス内に安全に保管され、ネットワーク上に流れることがないため、攻撃者が盗むことができません。

公開鍵で署名の正当性を検証するため、改ざんが困難です。

2. 認証プロセスのデバイス依存性

WebAuthnは、ユーザーのデバイス（例：スマートフォンやセキュリティキー）を認証プロセスに組み込むため、攻撃者が中間に割り込んでも認証を完了することができません。具体的には：

認証はデバイス固有の秘密鍵を使用するため、攻撃者が偽のデバイスを使用しても認証が成立しません。

生体認証（指紋や顔認証）やPINコードを組み合わせることで、さらにセキュリティが強化されます。

3. チャレンジレスポンス方式

WebAuthnはチャレンジレスポンス方式を採用しています。サーバーがランダムなチャレンジ（一時的な値）を生成し、クライアントがそのチャレンジに署名して応答します。この仕組みにより：

チャレンジは一度限りの値であり、再利用ができないため、リプレイ攻撃を防ぎます。

攻撃者が通信内容を盗んでも、次回の認証には利用できません。

4. フィッシング耐性

WebAuthnは、認証プロセスにおいてドメインの一致を確認します。ユーザーが認証を試みるウェブサイトのドメインが、公開鍵を登録した際のドメインと一致しない場合、認証が拒否されます。これにより：

攻撃者が偽のウェブサイトを作成しても、認証情報を盗むことができません。

ドメインの一致チェック（オリジンの確認）

Relay-Atack をされても、これにより検知可能、ということかな？

公開鍵の生成や認証時に、現在のウェブサイトのオリジン（プロトコル、ホスト、ポート）が、公開鍵登録時のオリジンと一致するかどうかを確認します。例えば：

登録時オリジン：https://example.com

認証時オリジン：https://example.com（一致 → 認証可）

認証時オリジン：https://malicious-site.com（不一致 → 認証不可）

フィッシング攻撃への防御

攻撃者が偽のウェブサイトを作成してユーザーから情報を盗もうとしても、オリジンが一致しなければ認証プロセスが完了しません。そのため、ユーザーの認証情報や秘密鍵が漏洩するリスクを大幅に低減できます。

5. セッションの乗っ取り防止

WebAuthnはセッション情報を暗号化し、認証プロセス全体を保護します。これにより、攻撃者がセッションを乗っ取ることが困難になります。

似たような名称の整理

Webセキュリティ関連技術一覧

基本全部ブラウザの判断なんだ。設定するのはサーバーでの応答時ってことか
SameOrigin Policy はブラウザ提供者によって行われていたのね

項目	説明	設定者	判断者	検証概要	設定の選択肢
SameSite 属性	Cookie に適用され、第三者サイトによるリクエストに Cookie が送信されるかを制御。	サーバー管理者	ブラウザ	Cookie の送信制御	Strict / Lax / None
Same Origin Policy	Web セキュリティモデルで、異なるドメイン間のリソースアクセスを制限。	ブラウザ開発者	ブラウザ	リソースアクセスの許可可否の判断	設定不要 (ブラウザデフォルト)
CORS	特定のオリジンに対してリソース共有を許可する仕組み。	サーバー管理者	ブラウザ	リクエスト/レスポンスのオリジン確認	許可するオリジンの指定
X-Frame-Options	ページが iframe に埋め込まれるかを制御する HTTP ヘッダー。	サーバー管理者	ブラウザ	iframe 埋め込みの許可/拒否確認	DENY / SAMEORIGIN / ALLOW-FROM
CSP	クロスサイトスクリプティング (XSS) やデータインジェクション攻撃を軽減するためのセキュリティポリシー。	サーバー管理者	ブラウザ	リソースの取得元や実行可能なスクリプトの制限	default-src, script-src など
HSTS	HTTPS を強制することで通信のセキュリティを向上させる仕組み。	サーバー管理者	ブラウザ	HTTPS 通信の強制	max-age, includeSubDomains など
Referrer Policy	リファラー情報の送信を制御する HTTP ヘッダー。	サーバー管理者	ブラウザ	リファラー情報の送信制御	no-referrer, origin など

HSTSプリロードの仕組み

HSTSプリロードリスト:

Googleが管理するリストで、主要なブラウザ（Chrome、Firefox、Edgeなど）がこのリストを参照します。

リストに登録されたドメインは、ブラウザが初回アクセス時からHTTPS通信を強制します。

登録の条件:

サイト全体がHTTPS化されていること。

サブドメインも含めてHTTPSが有効であること。

HSTSヘッダーに includeSubDomains と preload を設定していること。

利点:

初回アクセス時のHTTP通信を完全に排除し、SSLストリップ攻撃などの脅威を防ぎます。

ユーザーがHTTPリンクをクリックしても、ブラウザが自動的にHTTPSに切り替えます。

CSRF トークンおよび関連技術一覧

特徴	目的	主な用途	検証のタイミング	検証方法	検証の範囲	有効性の期間	例
CSRF トークン	CSRF攻撃防止	フォームやAPIリクエストの保護	リクエストの受信時	トークンの一致性を確認	セッションやリクエスト範囲	セッション中で有効	フォーム送信トークン
State	認証フローの整合性確認	OAuth2.0などの認証プロセス	認証要求後のレスポンス	State値の整合性を確認	認証要求とレスポンスのペア	認証フロー内で有効	OAuth2.0のStateパラメータ
Nonce	リプレイ攻撃防止	支払い処理や認証プロセス	各リクエスト送信時	過去に使用されたか確認	リクエストごとに一意性を保証	一度限り有効	支払いプロセスの一意値
Salt	データの一意性確保	パスワード保存やハッシュ作成	データ保存時	ランダム要素を追加	パスワードやトークン	長期間有効	パスワードのハッシュ
Pepper	セキュリティの強化	固定データによるセキュリティ向上	データ送信時	秘密の固定要素を混ぜて検証	サーバー保管の秘密データ	長期間有効	固定キーを使用するセッション管理
HMAC	データ改ざん防止・認証	データ完全性の保証と認証	データ送信時	ハッシュ値を確認	データ全体の改ざんチェック	長期間有効	APIリクエストの署名
JWT (JSON Web Token)	クライアント-サーバー間の安全な通信	アクセス認証トークン	リクエストの検証時	署名と有効期限を確認	トークンの有効性	有効期限内で有効	認証用アクセストークン
Secure Cookie	HTTPS通信時のCookie制限	Cookie送信のセキュリティ強化	Cookieの送信時	Cookie属性の確認	Cookie送信の条件を確認	セッション中で有効	HttpOnly属性を持つCookie

相変わらず、混乱している XSS vs CRSF vs SSRF

CSRFでは、攻撃者がユーザーのセッションを悪用して、サーバー側で意図しない動作を引き起こします。ここで重要なのは、サーバー側が「このリクエストが正規のものであるか」を見抜く技術と仕組みが欠かせません。例えば、CSRFトークンの検証やRefererヘッダーのチェックなどを活用することで、攻撃を防ぐことが可能になります。
一方、XSSでは、そもそもクライアントサイドで機密情報が盗まれないようにすることが重要です。入力値のエスケープ処理やCSP（Content Security Policy）の設定などが、これらの情報を守るための具体的な対策として挙げられます。

さらに言えば、両者は攻撃の方向性が異なるので、防御策もそれぞれ最適化する必要があります。CSRFでは「サーバーサイドの保護」、XSSでは「クライアントサイドの保護」がポイントですね。

攻撃手法	主な特徴	攻撃対象	目的	防御策
XSS	クライアントサイドでスクリプトを注入し、ブラウザ内で悪意のあるコードを実行する攻撃	クライアント（ブラウザ）	機密情報（Cookie、セッションIDなど）の取得、フィッシング	入力値のエスケープ処理、CSP導入
CSRF	被害者に正規のリクエストを送らせ、サーバー側で攻撃者の意図した操作を実行させる攻撃	サーバー	認証済みセッションの悪用による操作の強制	CSRFトークンの利用、Refererチェック
SSRF	サーバーを利用して内部リソースへリクエストを送信させる攻撃	サーバー（内部ネットワーク）	内部ネットワークや管理リソースへのアクセス	リクエストの検証、アクセス制限

Cookieに対するセキュリティ対策

セキュリティ対策	説明	初期値	設定者
HttpOnlyフラグ	JavaScriptでのアクセスを禁止し、XSS攻撃によるCookie盗難を防止します	無効 (`HttpOnly`未設定)	アプリケーション開発者
Secureフラグ	HTTPS接続の場合のみCookieを送信し、通信内容を盗聴されるリスクを軽減します	無効 (`Secure`未設定)	アプリケーション開発者
SameSite属性	クロスサイト間でのCookie送信を制限し、CSRF攻撃を防止します	`SameSite=None`	アプリケーション開発者
Cookieの暗号化	機密情報を暗号化することで、盗まれた場合でも解読を困難にします	未暗号化	システム管理者
有効期限の設定	必要以上に長い期間Cookieを保持せず、セッション終了後のリスクを軽減します	セッション終了時 (`Session`)	アプリケーション開発者
IPアドレスのバインディング	Cookieを特定のIPアドレスにバインドすることで、不正なアクセスを防ぎます	無効	システム管理者
サーバーサイドストレージ	Cookieを使わず、セッション情報をサーバー側で管理し、盗難リスクを回避します	Cookie依存	システム管理者
CSP（Content Security Policy）	信頼できないスクリプトの実行を防ぎ、Cookieへの不正なアクセスを制限します	未設定	アプリケーション開発者
定期的なCookie削除	古くなったCookieを削除することで、不要なリスクを回避します	未実施	システム管理者

CVSS, CWE, CVE

項目	CVSS	CWE	CVE
概要	脆弱性の影響度を数値で評価する標準	ソフトウェアの弱点を分類するリスト	脆弱性を識別するための一意の識別子
主な利用目的	脆弱性の深刻度評価	コード品質と脆弱性の特定	脆弱性管理と情報共有
スコア範囲	0.0 - 10.0	該当なし（リスト形式）	該当なし（識別子形式）
分類方法	ベース、テンポラル、環境の各指標	主題別分類（エントリー番号）	識別番号「CVE-西暦-連番」形式
利用対象	セキュリティエキスパート、管理者	開発者、設計者	セキュリティ専門家、開発者
公開元	FIRST	MITRE	MITRE
更新頻度	定期更新	継続的更新	脆弱性報告に応じて随時更新
主な活用例	脆弱性スコアによる対応優先順位付け	セキュリティチェックリスト作成	脆弱性情報の検索と追跡
具体例	CVE-2022-12345 (深刻度: 7.8)	CWE-79 (クロスサイトスクリプティング)	CVE-2023-45678 (詳細公開中)
具体例の説明	CVE-2022-12345は重大な脆弱性で、リモートから攻撃が可能な中程度のリスク。	CWE-79は、ユーザー入力を適切に処理しないことで発生する典型的な弱点。	CVE-2023-45678は公開中の脆弱性で、影響範囲が広く早急な対応が必要。

CVSS: https://jvndb.jvn.jp/cvss/#cvss

項目	CVSS (例)	説明
ベーススコア	7.8	脆弱性の特性そのものを評価（例: 攻撃ベクトル、影響範囲）。
環境値（Environmental Metrics）	6.5	組織の環境に基づくカスタマイズスコア（例: 資産の重要性、セキュリティ制御の存在）。
現状値（Temporal Metrics）	6.2	現在の状況に応じたスコア（例: 脅威の現実性、修正可能性、レポート信頼性）。
総合スコア	6.8	ベーススコアに環境値や現状値を加味した最終スコア。
スコアリング例	CVE-2022-12345	CVSSスコア: 7.8 → 環境や状況により加味される最終スコアは 6.8。

再度思いだすキーワード

Same-Origin Policy

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

2025/春 情報処理安全確保支援士 無事合格

背景

実際にやったこと

あとがき

ISMS

解凍指南

用語

CISOは「Chief Information Security Officer」

NISC（National center of Incident readiness and Strategy for Cybersecurity）

NIST（National Institute of Standards and Technology）

SASE（Secure Access Service Edge）

主な特徴

メリット

ID

アカウント管理

特権ID

AAAフレームワーク

プロビジョニング

プロビジョニングの具体的な例

FIDO認証（Fast Identity Online）

攻撃の種類

リバース vs フォワード

認証認可

JWT

罠サイトへのアクセス時の動き

クラウド

CDN って？

FQDN（Fully Qualified Domain Name）は

認証

SAML by POST

SAML by GET

ODIC

state

攻撃者がごまかせない理由

nonce

攻撃手法

ドメインフロンティング

Referer in Request Header from client

例

Referrer-Policy in Response Header from server

TLS.SNI

Host Header

リソースの識別

通信の正確性

負荷分散

セキュリティ

防御策

SNIフィルタリングの実施

CDNプロバイダとの連携

プロキシサーバーの利用

脆弱性の更新と修正

セキュリティプログラムの導入

browser への URL 入力と、Host の関係

ブラウザの動作

ブラウザの動作 2

PKI（公開鍵基盤）についての詳細まとめ

PKI全体像

デジタル証明書

CA（Certificate Authority）、RA（Registration Authority）、IA（Issuing Authority）

一連の手順、CSR(Certificate Signing Request)、CP(Certificate Policy)・CPS(Certification Practice Statement)

デジタル証明書のチェック方法

常時SSL化と通信内容の検査

TLS（Transport Layer Security）

HSTS（HTTP Strict Transport Security）

デジタル証明書の利用

時刻認証

証明書レベル

SSLおよびTLSバージョンの比較

1. セキュリティの向上

2. パフォーマンスの向上

3. 暗号化方式の変更

4. プロトコルの変更

具体例を交えたポイント

リプレイ攻撃防止のための策

RFC9162: Certificate Transparency

ファイヤーウォール

大枠

ファイヤーウォール比較

OSI 7

補足

2025/春情報処理安全確保支援士無事合格