エンジニア入門研修

用語解説

第14章 セキュリティの基本

この章では、支援ステータス機能を題材に、守る資産、情報の流れ、認証と認可、入力と出力、secret、依存関係といったセキュリティの基本を扱う。 ここでは、その章に出てくる業界で広く通用するセキュリティ用語を、研修の外でもそのまま使える形で解説する。

資産

  • 読み：しさん（asset）
  • 一言で言うと：守るべきデータ、機能、権限、可用性、信頼のこと。
  • くわしく：セキュリティを考えるときの出発点になる。守るものが曖昧なままだと、どのリスクが重要かを判断できない。先に資産を書き出すと、次にどんな脅威があるかを書ける。攻撃名から考えるのではなく、自分の機能で何を失うと困るかから考えられる。
  • 具体例：支援ステータス機能では、支援メモ、支援ステータス、担当関係、操作権限、Cookieやtoken、ログと監査記録が資産になる。
  • つまずきやすい点：資産はデータだけではない。権限、可用性、信頼のような目に見えにくいものも資産に含める。
  • 関連語：脅威（第14章）、攻撃者（第14章）、脅威モデリング（第14章）
  • テキスト本文での登場箇所：第14章「守る資産から始める」

脅威

  • 読み：きょうい（threat）
  • 一言で言うと：資産に対して起きてほしくない出来事のこと。
  • くわしく：資産を書き出した後に、その資産に何が起きると困るかを並べる。脅威を具体的に書くと、確認すべき場所が見えてくる。漠然と「危ない」と考えるより、誰が何をすると何が漏れるかを書くほうが対策につながる。脅威には優先度を付け、影響が大きいものから確認する。
  • 具体例：支援ステータス機能では、担当外メンターが支援メモを見る、受講者ロールがメンター向けAPIを呼ぶ、支援メモの文字列が画面でコードとして実行される、Authorization headerがログに出る、といった脅威がある。
  • つまずきやすい点：脅威は外部の悪意ある攻撃だけではない。誤操作や誤設定も資産を損なう脅威になる。
  • 関連語：資産（第14章）、攻撃者（第14章）、脅威モデリング（第14章）
  • テキスト本文での登場箇所：第14章「守る資産から始める」

攻撃者

  • 読み：こうげきしゃ（attacker / threat actor）
  • 一言で言うと：資産に脅威をもたらす可能性のある相手のこと。
  • くわしく：強い悪意を持った外部者だけを指すわけではない。権限を越えた利用者、誤操作をする利用者、壊れたクライアント、誤設定の運用、漏れたsecretを持つ第三者も、考える対象になる。攻撃者を広くとらえると、現実に起きやすいリスクを見落としにくくなる。誰が資産に手を届かせ得るかという視点で考える。
  • 具体例：支援ステータス機能では、担当外メンターが担当外の learnerId を指定して更新を試みる場合も、攻撃者の視点で確認する対象になる。
  • つまずきやすい点：攻撃者を「悪意のある外部のハッカー」だけに限定すると、誤操作や権限超えのような身近なリスクを見落とす。
  • 関連語：脅威（第14章）、脅威モデリング（第14章）、認可（第11章）
  • テキスト本文での登場箇所：第14章「守る資産から始める」

脅威モデリング

  • 読み：きょういモデリング（threat modeling）
  • 一言で言うと：資産、脅威、攻撃者、情報の流れを整理して、確認すべきリスクを見つける作業のこと。
  • くわしく：本章では、守る資産を書き、脅威を並べ、情報がどこから入りどこへ渡るかを線で見る流れがこれにあたる。コードファイルを読むだけではリスクの位置が見えにくい。情報の流れを描くと、入力検証、認可、出力エンコード、secret、依存関係のどこを確認すべきかが分かる。大がかりな手法でなくても、自分の機能の言葉で書けば十分役に立つ。
  • 具体例：支援ステータス機能で、browser から API、API から DB、API からログ、developer から AI、という流れを線で書き、各境界で何を確認するかを決める。
  • つまずきやすい点：脅威モデリングは専門家だけの大きな儀式ではない。小さな機能でも資産と流れを書くだけで効果がある。
  • 関連語：資産（第14章）、脅威（第14章）、攻撃者（第14章）
  • テキスト本文での登場箇所：第14章「守る資産から始める」「情報が渡る場所を線で見る」

OWASP Top 10

  • 読み：オワスプ トップテン（OWASP Top Ten）
  • 一言で言うと：Webアプリケーションでよく問題になるリスクを整理した代表的な資料のこと。
  • くわしく：OWASPはWebセキュリティの情報を公開している団体である。Top Tenは、順位を暗記するための表ではなく、見落としを減らすための目次として使う。自分の機能を確認するとき、抜けがないかを照らし合わせるチェックリスト代わりになる。セキュリティの参照情報は更新されるので、公式ページで最新の版を確認する習慣を持つ。
  • 具体例：支援ステータス機能を確認するとき、認可、入力検証、XSS、secret管理などの観点を、OWASP Top Tenの項目と照らし合わせて漏れがないか見る。
  • つまずきやすい点：順位や項目名を暗記しても安全にはならない。自分の機能に当てはめて確認するために使う。
  • 関連語：ASVS（第14章）、脅威モデリング（第14章）、多層防御（第14章）
  • テキスト本文での登場箇所：第14章「OWASPは、暗記表ではなく見落とし防止の目次である」

ASVS

  • 読み：エーエスブイエス（Application Security Verification Standard）
  • 一言で言うと：アプリケーションのセキュリティ確認項目を体系的にまとめた標準のこと。
  • くわしく：認証、認可、入力、出力、エラー、ログ、構成といった観点ごとに、確認すべき項目が整理されている。研修ではすべてを読む必要はないが、セキュリティ確認には体系的な観点があると知っておくと役に立つ。OWASP Top Tenが「よくあるリスクの目次」なら、ASVSは「確認項目の詳しいリスト」と考えると分かりやすい。最新版は公式ページで確認する。
  • 具体例：支援ステータス機能の認可確認をするとき、ASVSの認可に関する項目を参考に、ロールと担当関係の両方を見ているかを確かめる。
  • つまずきやすい点：全項目を満たすことが目的ではない。自分の機能に関係する観点を選んで使う。
  • 関連語：OWASP Top 10（第14章）、認可（第11章）、入力検証（第11章）
  • テキスト本文での登場箇所：第14章「OWASPは、暗記表ではなく見落とし防止の目次である」

多層防御

  • 読み：たそうぼうぎょ（defense in depth）
  • 一言で言うと：一つの対策に頼らず、複数の場所で重ねて守る考え方のこと。
  • くわしく：どこか一箇所が破られても、別の層で被害を止められるようにする。たとえば画面でボタンを隠すだけでなく、API側でも認可を確認する。入力検証だけでなく、DBへ渡すときのパラメータ化もする。万一のときに被害を小さくするため、DBアカウントの権限を必要最小限にすることも層の一つになる。一つの守りに過信しないための考え方である。
  • 具体例：支援ステータス更新では、画面でメンター以外にボタンを見せず、API側でもロールと担当関係を確認し、DB権限も更新に必要な範囲だけに絞る。
  • つまずきやすい点：画面で隠すことを認可だと思い込むと層が一つしかない。最後の守りを画面だけに置いてはいけない。
  • 関連語：最小権限（第14章）、認可（第11章）、出力エンコード（第14章）
  • テキスト本文での登場箇所：第14章「認証と認可を分ける」「SQLインジェクションは、入力がSQLの構造を変える問題である」

最小権限

  • 読み：さいしょうけんげん（least privilege）
  • 一言で言うと：必要な操作に必要な権限だけを与える考え方のこと。
  • くわしく：利用者やプログラムに、仕事に必要な範囲を超えた権限を持たせない。広い権限を持つと、万一それが悪用されたときの被害が大きくなる。逆に権限を絞っておけば、事故が起きても影響範囲を小さくできる。アプリが使うDBアカウントの権限も、この考え方で見直す。
  • 具体例：支援ステータス機能のアプリが支援ステータスの読み書きだけをするなら、DBアカウントにテーブル削除のような広い権限を持たせない。
  • つまずきやすい点：開発を楽にするために広い権限を付けたまま放置しやすい。後から絞るのは難しいので最初から必要な範囲にする。
  • 関連語：多層防御（第14章）、認可（第11章）、SQLインジェクション（第14章）
  • テキスト本文での登場箇所：第14章「SQLインジェクションは、入力がSQLの構造を変える問題である」

認証

  • 読み：にんしょう（authentication）
  • 一言で言うと：利用者が誰かを確認すること。→第11章
  • くわしく：→第11章。セキュリティの観点では、認証はAPI側で必ず確認する。画面に入れたかどうかではなく、APIを呼んだ利用者が本人かを見る。未ログインの利用者がAPIを呼んだら401で拒否する。Cookieで認証するか、Authorization headerで認証するかによって、CSRFやsecretの扱いも変わる。
  • 具体例：支援ステータス更新APIで、未ログインの利用者が呼んだ場合は401を返す。
  • つまずきやすい点：認証と認可を混ぜると、ログイン済みなら何でもできる設計になりやすい。本人確認と操作許可は別である。
  • 関連語：認可（第11章）、CSRF（第14章）、secret（第5章）
  • テキスト本文での登場箇所：第14章「認証と認可を分ける」

認可

  • 読み：にんか（authorization）
  • 一言で言うと：その利用者がその操作をしてよいかを確認すること。→第11章
  • くわしく：→第11章。セキュリティの観点では、ログイン済みであることと、対象データを操作してよいことは別だと意識する。認可はAPIがDBへ進む前に確認する。ロールだけでなく担当関係も見る。403を返す場合でも、内部で更新してからエラーにしていないか、保存値が変わっていないかまで確認する。
  • 具体例：支援ステータス機能で、ログイン中のメンターでも担当外の受講者は更新できず、担当外メンターのリクエストは403になり、保存値は変わらない。
  • つまずきやすい点：対象IDが存在するかだけを見て、担当外かどうかを見ないと認可漏れになる。存在確認と権限確認は別である。
  • 関連語：認証（第11章）、最小権限（第14章）、多層防御（第14章）
  • テキスト本文での登場箇所：第14章「認証と認可を分ける」「ID直接指定のリスクを見る」

入力検証

  • 読み：にゅうりょくけんしょう（input validation）
  • 一言で言うと：外から来た値の形式、範囲、業務ルールを確認すること。→第11章
  • くわしく：→第11章。セキュリティの観点では、画面でselectを使っていても、APIに来る値を信用しない。ブラウザの開発者ツールやcurlを使えば、画面にない値も送れる。許可する値を明確にし、それ以外を拒否する。入力検証は、後続の処理や表示を壊さない土台にもなる。
  • 具体例：支援ステータスでは、none needs_support in_progress resolved だけを許可し、空文字、null、許可されていない文字列、型が違う値を拒否する。
  • つまずきやすい点：入力検証とSQLインジェクション対策は役割が違う。許可値検証だけでは、DBへ渡すときの構造破壊は防げない。
  • 関連語：認可（第11章）、SQLインジェクション（第14章）、パラメータ化クエリ（第14章）
  • テキスト本文での登場箇所：第14章「入力値は、画面から来ても信用しない」

SQLインジェクション

  • 読み：エスキューエルインジェクション（SQL injection）
  • 一言で言うと：信頼できない入力が、SQLの構造を変えてしまう問題のこと。
  • くわしく：ユーザー入力をSQL文字列に直接つないでいると、入力が命令の一部として解釈されてしまうことがある。これにより、本来見えないデータが取り出されたり、データが書き換えられたりする。危ない文字を頑張って消す発想だけでは不十分である。大切なのは、入力をSQLの命令として解釈させないことで、基本はパラメータ化クエリやORMの安全なAPIを使う。
  • 具体例：支援ステータス機能では、learnerId、supportStatus、検索条件、支援メモがSQLへ渡る可能性があり、これらを文字列連結でqueryへ埋め込んでいないかを見る。
  • つまずきやすい点：許可値検証をしていても、DBへ渡すときに文字列連結していれば防げない。パラメータ化と入力検証は両方必要である。
  • 関連語：パラメータ化クエリ（第14章）、入力検証（第11章）、最小権限（第14章）
  • テキスト本文での登場箇所：第14章「SQLインジェクションは、入力がSQLの構造を変える問題である」

パラメータ化クエリ

  • 読み：パラメータかクエリ（parameterized query / prepared statement、プリペアドステートメント）
  • 一言で言うと：値とSQLの命令部分を分けて渡すことで、入力が構造を壊さないようにする仕組みのこと。
  • くわしく：SQL文の中に値を直接つなぐのではなく、値の入る場所を印で示しておき、実際の値は別に渡す。こうすると、入力に特殊な文字が含まれていてもSQLの命令としては解釈されない。SQLインジェクションを防ぐ基本の方法である。多くのライブラリやORMが安全なAPIとして提供している。プリペアドステートメントとも呼ばれる。
  • 具体例：支援ステータス更新で learnerId をqueryに渡すとき、文字列連結ではなくプレースホルダを使い、値をパラメータとして渡す。
  • つまずきやすい点：パラメータ化は構造破壊を防ぐが、業務上受け入れてよい値かまでは見ない。許可値検証と組み合わせる。
  • 関連語：SQLインジェクション（第14章）、入力検証（第11章）、ORM（第14章）
  • テキスト本文での登場箇所：第14章「SQLインジェクションは、入力がSQLの構造を変える問題である」

XSS

  • 読み：エックスエスエス（Cross-Site Scripting）
  • 一言で言うと：信頼できない入力が、ブラウザ上でコードとして実行される問題のこと。
  • くわしく：ユーザーが入力した名前、メモ、コメント、検索語、エラーメッセージなどを画面に表示するときに起きやすい。入力にスクリプトが含まれていて、それがそのままHTMLとして解釈されると、ブラウザ上でコードが動いてしまう。防ぐには、表示する文脈に合わせて出力エンコードする。フレームワークの自動エスケープを使い、HTMLを直接挿入するAPIやエスケープ無効化の仕組みは慎重に扱う。
  • 具体例：支援ステータス機能で、支援メモに <script> を含む文字列が入っても、画面ではテキストとして表示され、コードとして実行されないことを確認する。
  • つまずきやすい点：画面の本文だけが対象だと思いやすい。エラー表示、トースト通知、検索結果、空状態、管理画面など、外部入力が表示される場所すべてを確認する。
  • 関連語：出力エンコード（第14章）、エスケープ（第14章）、入力検証（第11章）
  • テキスト本文での登場箇所：第14章「XSSは、入力がブラウザでコードになる問題である」

CSRF

  • 読み：シーエスアールエフ（Cross-Site Request Forgery）
  • 一言で言うと：ログイン中のブラウザから、利用者が意図しない更新requestが送られる問題のこと。
  • くわしく：Cookieは条件が合うとブラウザが自動で送るため、Cookieでログイン状態を持つ更新APIでは、別のサイトから送られたrequestでもログイン済みとして扱われることがある。対策は認証方式やフレームワークによって異なり、CSRF token、Cookieの SameSite 属性、送信元確認などを検討する。基本として、GETで状態を変更せず、変更操作にはPOST、PATCH、PUT、DELETEなど意図が分かるmethodを使う。
  • 具体例：支援ステータスを変更する操作は、GETではなくPATCHを使い、フレームワークの推奨に従ってCSRF対策を確認する。
  • つまずきやすい点：methodを分けるだけで完全に安全になるわけではない。Cookie認証かAuthorization header認証かで必要な対策が変わる。
  • 関連語：認証（第11章）、secret（第5章）、出力エンコード（第14章）
  • テキスト本文での登場箇所：第14章「CSRFは、ログイン中のブラウザから意図しない更新が送られる問題である」

出力エンコード

  • 読み：しゅつりょくエンコード（output encoding）
  • 一言で言うと：表示する文脈に合わせて、値がコードとして解釈されないようにすること。
  • くわしく：同じ文字列でも、HTML本文、HTML属性、URL、JavaScriptの中では安全な出し方が違う。出力エンコードは、表示する場所ごとに、値を表示用の文字へ変換して、コードとして解釈されないようにする。XSSを防ぐ中心的な対策である。多くのフレームワークが通常のテキスト表示で自動的にこれを行う。
  • 具体例：支援メモを画面に表示するとき、< や > のような文字がHTMLの記号としてではなく文字として表示されるようにする。
  • つまずきやすい点：表示する文脈ごとに必要なエンコードが違う。HTML本文用のエンコードを属性やURLにそのまま流用しても安全とは限らない。
  • 関連語：XSS（第14章）、エスケープ（第14章）、入力検証（第11章）
  • テキスト本文での登場箇所：第14章「XSSは、入力がブラウザでコードになる問題である」

エスケープ

  • 読み：エスケープ（escape）
  • 一言で言うと：特殊な意味を持つ文字を、ただの文字として扱わせるための変換のこと。
  • くわしく：HTMLやSQLなどでは、一部の文字が構造を表す特別な意味を持つ。エスケープは、その文字を表示用や値用の表現に置き換えて、構造の一部として解釈されないようにする。出力エンコードはエスケープを使って実現されることが多い。フレームワークの自動エスケープを無効化すると危険になるので、その仕組みを使うときは慎重に判断する。
  • 具体例：支援メモに含まれる < を、HTMLでは画面に文字として見える形へエスケープして、タグの開始として解釈されないようにする。
  • つまずきやすい点：エスケープを無効化する仕組み（HTMLを直接挿入するAPIなど）を安易に使うとXSSの穴になる。
  • 関連語：出力エンコード（第14章）、XSS（第14章）、SQLインジェクション（第14章）
  • テキスト本文での登場箇所：第14章「XSSは、入力がブラウザでコードになる問題である」

secret

  • 読み：シークレット（secret）
  • 一言で言うと：API key、password、token、private key、Cookieなど、外へ出してはいけない値のこと。→第5章
  • くわしく：→第5章。セキュリティの観点では、secretはソースコードだけから漏れるわけではない。git diff、.env、server log、browser Network、PR本文、issueやチャット、スクリーンショット、AIに渡す内容など、複数の場所を見る。見つけても消すだけでは足りないことがあり、すでに共有されたsecretは無効化や再発行が必要になる。どこに出たか、誰が見られたか、どの環境に影響するかを確認する。
  • 具体例：支援ステータス機能のログにAuthorization headerやCookieが出ていないか、PR本文やスクリーンショットにtokenが写り込んでいないかを確認する。
  • つまずきやすい点：secretをソースコードの中だけで探すと、ログやNetwork、提出物からの漏れを見落とす。
  • 関連語：環境変数（第5章）、認証（第11章）、機微情報（第14章）
  • テキスト本文での登場箇所：第14章「secretは、コード以外からも漏れる」

機微情報

  • 読み：きびじょうほう（sensitive information）
  • 一言で言うと：漏れると困る、慎重に扱うべき情報のこと。
  • くわしく：secretは認証や接続に使う鍵のような値だが、機微情報はそれとは種類が違う。実名、メールアドレス、個人情報、実際の支援メモなどが含まれる。secretほど鍵としての性質は持たないが、見られると困るため、提出物やAIに渡す内容には含めない。スクリーンショットやログにも写り込むことがあるので注意する。
  • 具体例：支援ステータス機能の演習では、実在の受講者名や実際の支援メモを提出物に含めず、サンプルデータに置き換える。
  • つまずきやすい点：機微情報とsecretを同じ対策で済ませようとしがちだが、secretは無効化や再発行が必要になる点で扱いが違う。
  • 関連語：secret（第5章）、資産（第14章）
  • テキスト本文での登場箇所：第14章「secretは、コード以外からも漏れる」

依存関係

  • 読み：いそんかんけい（dependency）
  • 一言で言うと：アプリが動くために追加で必要とするライブラリやパッケージ。→第5章
  • くわしく：→第5章。セキュリティの観点では、依存関係は自分のコードの外にあるリスクである。自分のコードがきれいでも、古いライブラリや既知の脆弱性があるライブラリはリスクになる。依存関係を書くファイルとversionを固定するlock fileを見て、監査コマンドで脆弱性を確認する。結果が出ても機械的にversionを上げるのではなく、影響範囲、修正版、互換性、テスト結果を見て判断する。
  • 具体例：支援ステータス機能で、package.json やlock fileを見て、監査コマンドで脆弱性が報告されたpackageを確認し、対応するもの・しないものを記録する。
  • つまずきやすい点：警告が出たら全部すぐ上げればよいわけではない。逆に、警告を見なかったことにするのもいけない。判断と理由を記録する。
  • 関連語：監査コマンド（第14章）、lockファイル（第5章）、secret（第5章）
  • テキスト本文での登場箇所：第14章「依存関係は、自分のコードの外にあるリスクである」

監査コマンド

  • 読み：かんさコマンド（audit command）
  • 一言で言うと：依存関係に既知の脆弱性がないかを確認するコマンドのこと。
  • くわしく：使っているライブラリの一覧を、既知の脆弱性データベースと照らし合わせて報告してくれる。package managerやエコシステムごとに npm audit、pnpm audit、yarn audit、pip-audit、bundle audit などがある。コマンド名を暗記するより、リポジトリのREADME、Makefile、CI設定にある標準コマンドを使うことが大切である。結果は判断の材料であり、そのまま機械的に修正すればよいわけではない。
  • 具体例：支援ステータス機能のリポジトリで標準とされている監査コマンドを実行し、脆弱性が報告されたpackageと対応方針を記録に残す。
  • つまずきやすい点：自分の好きなコマンドを使うのではなく、プロジェクトで決められた監査コマンドを使う。結果の解釈も人が行う。
  • 関連語：依存関係（第5章）、lockファイル（第5章）、CI（第16章）、CD（第16章）
  • テキスト本文での登場箇所：第14章「依存関係は、自分のコードの外にあるリスクである」

NIST SSDF

  • 読み：ニスト エスエスディーエフ（NIST Secure Software Development Framework、SP 800-218）
  • 一言で言うと：安全なソフトウェア開発の作業を体系化した、米国NISTによる枠組み。
  • くわしく：SSDFは、設計・実装・テスト・運用の各段階でやるべき高水準のプラクティスをまとめている。OWASP Top 10が「起きやすい弱点の目次」、ASVSが「確認項目の体系」だとすると、SSDFは「開発プロセス全体で何をすべきか」を示す。個別の脆弱性対策だけでなく、組織や手順として安全性をどう担保するかを考えるときの参照になる。
  • 具体例：支援ステータス機能の開発で、入力検証やsecret管理を場当たり的に直すのではなく、開発フローのどの段階で誰が確認するかをSSDFの観点で決める。
  • つまずきやすい点：研修の小さな課題で全項目を満たす必要はない。まずは存在と位置づけ（プロセスの枠組み）を知り、必要なときに参照する。
  • 関連語：OWASP Top 10（第14章）、ASVS（第14章）、資産（第14章）
  • テキスト本文での登場箇所：第14章「OWASPは、暗記表ではなく見落とし防止の目次である」

ORM

  • 読み：オーアールエム（Object-Relational Mapping／オブジェクト関係マッピング）
  • 一言で言うと：DBのテーブルとプログラムのオブジェクトを対応づけ、SQLを直接書かずにデータを読み書きする仕組み。
  • くわしく：ORMを使うと、行をオブジェクトとして扱い、用意された安全なAPIで検索や更新ができる。文字列連結でSQLを組み立てないため、SQLインジェクションを避けやすい。一方で発行されるSQLが見えにくく、知らないうちに非効率なquery（N+1など）が出ることもある。便利さと、裏で何が起きているかの把握はセットで考える。
  • 具体例：支援ステータスの保存をORM経由で行えば、値はパラメータとして安全に渡る。ただし一覧取得の書き方によってはN+1 queryになっていないかを確認する。
  • つまずきやすい点：ORMなら何でも安全・高速と思い込む。生成されるSQLとquery回数は、ログやトレースで確認する。
  • 関連語：パラメータ化クエリ（第14章）、repository（第11章）、N+1 query（第17章）、SQL（第10章）
  • テキスト本文での登場箇所：第14章「SQLインジェクションは、入力がSQLの構造を変える問題である」

教材を検索