メインコンテンツまでスキップ

セキュリティ技術入門で最初にそろえる基盤知識

この教材の要約​

Web脆弱性、認可、クラウド、ログを学ぶ前に必要な、ネットワーク、OS、認証、セッションの共通前提をそろえます。

概念図​

技術基盤
├─ ネットワーク
│  ├─ TCP/IP
│  ├─ DNS
│  └─ HTTP/HTTPS
├─ 実行環境
│  ├─ OS
│  └─ アプリケーション
├─ IDと状態
│  ├─ 認証
│  ├─ 認可
│  └─ セッション
└─ クラウド
   └─ 共有責任モデル

はじめに​

セキュリティ技術入門は、脆弱性の名前を増やすことから始めるべきではありません。
その前に、ネットワーク、OS、認証、クラウドといった基盤の言葉をそろえる必要があります。1

土台が曖昧なままだと、設定不備、認可不備、ログ監視、インシデント対応の話も断片的な知識で終わりやすくなります。
この章では、技術専門トラックを読むために最低限そろえておきたい共通知識を整理します。

なぜ共通基盤が必要なのか​

技術領域の実務では、次のような会話が日常的に出てきます。

  • この通信はどこからどこへ流れるのか
  • その権限は誰に付いているのか
  • このエラーは認証の問題か認可の問題か
  • ログはどこに残るのか
  • クラウド側と自社側の責任境界はどこか

これらを理解するには、個別製品の知識より前に、構造を読むための共通語彙が必要です。

ネットワークの基本​

TCP/IPをざっくり押さえる​

システムは単体で動くのではなく、端末、アプリ、ミドルウェア、外部サービスが通信して成り立っています。
TCP/IPは、その通信の土台です。1

入門段階で最低限理解したいのは、次の観点です。

  • どの端末、どのサーバ、どのサービスが通信しているか
  • どのポートを使っているか
  • 外部通信か、内部通信か
  • その通信が想定どおりか

攻撃や不正動作は、しばしば「想定外の通信」として表れます。

DNSは名前解決の入口​

DNSは、利用者やシステムが使う名前を接続先へ変換する仕組みです。
ここが崩れると、正しいつもりの通信が誤った先へ向かったり、不審な外部通信の手がかりが見えたりします。

この段階では、DNSを「ただ名前を引くもの」ではなく、通信先を理解するための重要な観測点として捉えることが重要です。

HTTP/HTTPSはWebの基本​

業務システムやAPIの多くはHTTP系の通信を使います。
URL、ヘッダ、Cookie、リクエスト、レスポンスといった概念が分からないと、Web脆弱性や認証セッションの理解が難しくなります。1

HTTPSは暗号化されたHTTPですが、暗号化されているから安全という単純な話ではありません。
何と通信しているか、誰を信頼しているか、証明書がどう扱われているかまで見る必要があります。

OSと実行環境の基本​

プロセス、権限、サービス​

アプリケーションはOSの上で動き、プロセスとして実行されます。
どのユーザ権限で動いているか、どのサービスとして起動しているか、どこまでの権限を持つかは、事故影響に直結します。1

たとえば、不要に強い権限で動くサービスは、侵害されたときの被害も大きくなります。

LinuxとWindowsを「操作画面」ではなく「管理対象」として見る​

セキュリティ技術入門トラックでは、OSを単なる利用環境ではなく、設定、権限、サービス、ログの管理対象として見ます。

最低限押さえたい視点は次のとおりです。

  • どのユーザが何をできるか
  • どのサービスが起動しているか
  • どこに設定があるか
  • どこにログが残るか

認証、認可、セッションの違い​

認証​

認証は、「その人、またはそのシステムが誰か」を確認することです。
IDとパスワード、多要素認証、証明書、トークンなどがここに関わります。

認可​

認可は、「その人やシステムが何をしてよいか」を決めることです。
ログインできることと、特定データを見てよいことは別の問題です。1

実務では、この2つを混同すると、ログインしているのに権限チェックが漏れる事故が起きやすくなります。

セッション​

セッションは、認証済み状態を継続して扱うための仕組みです。
Cookieやトークン、タイムアウト、再認証の扱いがここに関わります。

セッション管理が弱いと、なりすましや権限不正利用につながるため、認証そのものと同じくらい重要です。

クラウドの基本視点​

クラウドは「誰かが全部守ってくれる環境」ではない​

クラウドでは、ベンダと利用者の間で責任が分かれます。1

たとえば、基盤の一部はクラウド側が守っていても、次のようなものは利用者側の責任になることがあります。

  • アカウントや権限の設計
  • データの共有範囲
  • 設定ミスの防止
  • ログ取得と監視

そのため、クラウドのセキュリティは「クラウドだから安全」ではなく、責任境界を理解して管理することが重要です。

この章で覚えるべきこと​

この章で最低限持ち帰りたいのは、次の感覚です。

  • 通信には流れがあり、観測点がある
  • OSにはプロセス、権限、サービス、ログという管理対象がある
  • 認証と認可は別物である
  • セッション管理は認証の延長として重要である
  • クラウドは責任分界を理解して使う必要がある

つまずきやすい誤り​

用語を知っているつもりで実体を見ない​

HTTP、DNS、権限、認証の言葉を知っていても、実際に「何がどこで起きているか」を結び付けられないと実務では使えません。

ログインできたことを安全だと思う​

認証が通ることと、適切な権限で安全に使えることは別です。
この区別がつかないと、認可不備や権限過多を見落としやすくなります。

クラウドをブラックボックスにする​

クラウドサービスでも、権限、設定、公開範囲、ログは自分たちで見なければなりません。
責任境界を考えない使い方は危険です。

ミニ確認​

  1. 認証と認可はどう違うか
  2. DNSやHTTPはなぜセキュリティ理解に必要か
  3. OSを管理対象として見るとき、何を意識すべきか
  4. クラウドで利用者側が考えるべきことには何があるか

次に読む​

関連トピック​

関係教材使い方
前提セキュリティ技術入門トラックの考え方技術入門で扱う範囲を確認する
次に読むWebアプリで押さえるべき代表的な脆弱性基盤知識を脆弱性理解へつなげる
関連認証、認可、秘密情報管理の落とし穴認証、認可、セッションを深掘りする

参考資料（出典）​

Footnotes​

  1. IETF, RFC 9293: Transmission Control Protocol (TCP) / RFC 1034: Domain Names - Concepts and Facilities / RFC 9110: HTTP Semantics。TCP、DNS、HTTP の基礎を参照。https://datatracker.ietf.org/doc/html/rfc9293 https://datatracker.ietf.org/doc/html/rfc1034 https://datatracker.ietf.org/doc/html/rfc9110; NCSC, Device security guidance。OS と端末を管理対象として扱う観点を整理。https://www.ncsc.gov.uk/collection/device-security-guidance; NIST CSRC Glossary, authentication。認証の基本定義を参照。https://csrc.nist.gov/glossary/term/authentication; OWASP Cheat Sheet Series, Authorization / Session Management。認可とセッション管理の観点を整理。https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html; NCSC, Cloud security shared responsibility model。クラウドの責任分界を整理。https://www.ncsc.gov.uk/collection/cloud/understanding-cloud-services/cloud-security-shared-responsibility-model ↩ ↩2 ↩3 ↩4 ↩5 ↩6