セキュリティエンジニアの面接：認証ログから調査と対策を説明する

認証ログに失敗と成功が続いているとき、「成功したので問題なし」とも「IPが変わったので侵害確定」とも言い切れません。セキュリティエンジニアの面接では、観察できた事実から仮説を立て、次に必要な証拠と対策の条件を説明する練習が役立ちます。

この記事では、架空の認証ログを使い、時系列、MFA、セッション、リソースへのアクセスを分けて調査します。どの記録がどの判断を支え、何がまだ分からないかを明確にしながら、次の調査へ進めます。

根拠の区分： ログの読み方や対応の考え方はNIST、OWASP、Microsoftの公式資料を参照します。ログの項目名、利用者、時刻、回答例はPracHub独自の練習です。実際のEntraログのエクスポート形式ではなく、特定企業の面接再現や候補者レポートでもありません。解析はオフラインで行い、実アカウントへの操作や攻撃は実施しません。

Detect Security Attacks in Text Logs Using Sliding-Window Rulesを練習するときも、ルールに一致することと、現実の攻撃を確定することを区別して考えましょう。

まず、応募先で扱うセキュリティの範囲を確認する

「セキュリティエンジニア」は、監視・インシデント対応、製品の安全設計、クラウド設定、診断などで担当範囲が変わります。この記事は認証ログを調べる防御側のケースです。侵入テストの手順や脆弱性診断を網羅するものではありません。求人票で扱うシステムと責任範囲を確認してから、経験を結び付けます。

NIST SP 800-61 Rev.3は2025年4月公開の資料で、インシデント対応をサイバーセキュリティのリスク管理へ組み込む考え方を扱います。本記事の細かな調査順序は、その公式な面接採点表ではなく、独自ケースを説明するための提案です。NIST公式資料

面接の開始時には、「対象は一つの組織の認証基盤か」「端末やアプリの監査ログも参照できるか」「自分に調査と封じ込めのどちらの権限があるか」を確認します。参照権限で調査を担当するなら、確認した証拠と推奨案を、対策を実行できる担当者へ渡すところまで具体的に説明できます。

九つのイベントと、一つの再配送を読む

全イベントの日付は2026年10月1日、時刻はUTCです。表の並びを、そのまま収集順や発生順とみなさず、発生時刻と取り込み時刻を確認します。利用者やセッションのラベルは架空で、実際の秘密情報ではありません。

e08は08:05:00に取り込まれ、e05の同じ内容は08:06:00にもう一度配送された設定です。生の入力は10行ですが、一意なイベントは9件です。再配送の取り込み時刻が違うことだけで、別の認証成功として数えてはいけません。

IPには文書用のアドレスを使用しています。RFC 5737で定められた例示用の範囲であり、実際の攻撃元や接続先を示すものではありません。RFC 5737

最初の観察として言えるのは、二つの利用者に対する失敗、R3での追加認証拒否、S9での成功と後続の読み取りです。「パスワードスプレー」「セッション盗用」「情報流出」は、追加証拠なしにこの表だけで確定しません。

認証の段階と、許可された操作を混同しない

e03はパスワードの受理まで、e04はR3のMFA拒否までを示します。R3が後で成功した記録は、この入力にはありません。e05は別の要求R5・セッションS9なので、時刻が近いだけでR3の成功としてつなげないようにします。

Microsoftの公式資料では、サインインログの認証詳細に、使った認証方式や各試行の結果が含まれると説明しています。要件がトークン内の情報によって満たされ、利用者が毎回対話的に認証するとは限らない点も示されています。本ケースの mfa: satisfied も、その場で本人が新しい承認操作をした証拠としては扱いません。認証ログの詳細

また、Microsoftのサインインログには対話型と非対話型などの種類があります。e06のトークン更新を新しい対話型サインインと同じ件数に混ぜると、活動の見え方が変わります。ただし、本ケースのイベント分類は独自の簡略形であり、製品の全分類との一対一の対応を保証しません。サインインログの種類

認証と認可も分けます。e05は認証成功の記録、e07はアプリ側の読み取り記録です。読み取りが正当な権限で行われたか、doc7が機密情報か、本人の業務だったかは別に調べます。4096バイトという値だけでは、機密情報の流出や被害規模を判断できません。

原本を残し、調査用の時系列を作る

解析では元の入力を変更せず、イベントIDと内容を照合して、調査用に重複を除いた一覧を別に作ります。同じID・同じ内容のe05は一件として扱いますが、二つの配送記録は元の入力に残します。本実装は先に読み取った配送を表示用の代表行にし、元の二行は残します。最も早い取り込み時刻を必ず選ぶ実装ではありません。

本ケースでは、内容の比較から ingested_at だけを除外します。event_id、発生時刻、利用者、動作、IPなどが同じであれば再配送です。同じIDでIPや利用者が違えば、黙って上書きせず解析を停止します。この契約は独自のものです。実際のサービスで同じIDの詳細が後から補完されるなら、更新履歴として扱う設計が必要です。

発生時刻で並べると、順序は次のようになります。

e01 → e02 → e03 → e08 → e04 → e05 → e06 → e07 → e09

遅れて届いたe08は、発生時刻ではe03とe04の間に入ります。取り込みが遅いことを理由に、08:05の新しいサインインとして置くと、調査対象の時間関係が変わってしまいます。時計のずれや発生時刻の信頼性は、実環境では別に確認します。

調査範囲を [08:00:00, 08:04:00) とすると、最初の時刻を含み、最後の時刻は含みません。この範囲の一意イベントは8件で、e09は次の範囲です。境界を決めると、隣り合う検索範囲でe09を二重に数えず、同じ条件で件数を比較できます。これも本ケースの検索契約で、全製品の検索構文が同じとは限りません。

IPよりも、要求とセッションの対応を確認する

同じ利用者u17かつS9で絞ると、e05、e06、e07が残ります。サインイン成功、更新、読み取りの連鎖として説明できます。R3のMFA拒否も、別セッションS10のe09も、このS9の連鎖には入れません。

session_events = [
    row for row in timeline
    if row["user"] == "u17" and row["session"] == "S9"
]
# e05, e06, e07

この相関は、同じラベルが同じセッションを指すという入力契約に依存します。製品ごとのrequest ID、correlation ID、session IDの意味を確認し、単に同じ文字列があるだけで別テナントや別アプリを横断して結合しないようにします。

e08のu19も203.0.113.7を使っています。共有出口の可能性はありますが、それが会社のVPNであるとはまだ分かりません。Microsoftの公式資料も、IPアドレスと端末の物理的な所在地に確定的な対応はなく、VPNなどの影響を受けると説明しています。IPと位置情報の注意点

したがって「同じIPだから同一人物」「別IPだから移動不可能な攻撃」とは判断しません。端末の管理状態、認証の詳細、既知の出口、利用者への確認、アプリの操作履歴などを組み合わせます。これらは追加調査の候補であり、本実験で取得済みのデータではありません。

観察、仮説、対策の条件を一つの表にする

面接では、仮説を一つに固定せず、反対の説明が成立するかも確認します。以下は本ケースに対する調査提案です。現実のアカウントで対策を実行した記録ではありません。

「侵害が確定するまで何もしない」という意味ではありません。重大な不正操作が続いている証拠があれば、調査と並行して既定の手順で影響を抑える判断が必要です。逆に、根拠の薄いIP単位の遮断は、共有出口の正当な利用者を巻き込む可能性があります。

判断の理由、対象、実行者、承認・権限、開始時刻、解除条件を記録します。自分が判断できる範囲を越えるときは、必要な証拠と推奨案を担当者へ渡します。これは調査ケースの説明であり、面接中に実システムを変更する提案ではありません。

封じ込めを提案したら、検証と復旧まで説明する

仮に調査担当者がS9の不正利用を確認した場合、組織の手順に従ってセッションの無効化やアカウント保護を検討します。具体的に何を止めるかは、ID基盤、トークンの寿命、アプリの認可方式、利用者への影響によって変わります。全システムが即座に同じ結果になると約束しません。

対策後の確認では、「ボタンを押した」ではなく、対象の操作が拒否されるか、関連する新規認証がどう扱われるか、正当な利用者が復旧できるかを調べます。監査ログが到着するまでの遅延も考慮し、記録がまだないことだけで対策成功と判断しないようにします。

復旧は、単に制限を外すことではありません。原因の見直し、必要な資格情報の保護、端末と権限の確認、利用者への連絡、再発の監視を含めて担当者と計画します。本ケースでは対策も復旧も実行していないため、これらは確認すべき条件として提示します。

ログ自体の扱いにも注意します。OWASPは、パスワードやアクセストークンなどを直接記録せず、必要に応じて除去・マスキング等を行う考え方を示しています。実務でセッション相関を残す場合も、秘密として使える値をそのまま共有する必要はありません。OWASP Logging Cheat Sheet

本ケースのS9は、認証に使えない架空の相関ラベルです。原本の保存とアクセス制限、共有用の情報削減を分け、証拠を残すために秘密情報を無制限に収集する設計にはしません。

オフライン検証で確認した26項目と限界

Python 3.12.14で26項目のアサーションを実行し、すべて成功しました。10行から9イベントを作ること、e05の再配送の識別、e08を含む発生時刻順、半開区間の8件、S9の三件の連鎖、別利用者・別セッションの除外などを確認しました。

同じイベントIDでIP、利用者、動作が変わる三つの矛盾も拒否しました。オフセットのない時刻と不正な時刻文字列は拒否し、17:00:00+09:00 と 08:00:00Z が同じ時点であることを確認しました。入力の順序を逆にした場合も、イベントIDの時系列は一致します。

入力データが解析によって変更されないことも、比較と正規化JSONのハッシュで確認しています。このハッシュは入力オブジェクトの不変性を示す補助証拠です。原本ファイルの改ざん防止、保管庫のアクセス制御、法的な証拠管理を実装したという主張ではありません。

これらのチェックは、合成ログを指定どおり並べ、数え、関連付けた検証です。不正ログインの検出率、誤検知率、本人性、実際の侵害は検証していません。ログの欠落、時計のずれ、製品の集約更新、保持期間、実SIEMとの接続も対象外です。解析コードの正しさと、調査結論の正しさを区別して説明しましょう。

面接で証拠から次の行動へつなげる

回答例はこうまとめられます。「R3のMFA拒否と、別要求のS9成功を分けます。S9では成功、更新、読み取りの三件を相関できますが、本人の操作かは未確認です。遅延到着したu19の記録から、同じIPがu17とu19の記録に現れることも分かります。実際に同じ出口を使ったかは追加確認が必要です。端末と出口、認証詳細、アプリ監査を確認し、不正利用の根拠と影響に応じて権限のある担当者へ封じ込め案を渡します。対策後の拒否結果と正当利用者の復旧まで確認します」。

過去の経験を説明する場合も、自分が調べた記録、立てた仮説、担当者が決めた対策、確認した結果を分けます。未解決の事案なら、その時点で分かっていた範囲を話します。チームの結論を自分一人の調査成果にせず、担当範囲と判断に使った証拠を示してください。

次の問題は、このケースを別条件へ移すための練習です。同じ企業の選考セットではなく、問題の前提も異なります。

この表のS9の三件を確認してから、ログと時間窓の問題で、観察した事実、成立し得る別の説明、次に集める証拠を一つずつ書いてみてください。対策名を増やす前に、その行動を選ぶ理由と確認方法を説明する練習になります。

Sources and Further Reading

• NIST SP 800-61 Rev.3 — インシデント対応をリスク管理へ組み込む公式資料。
• Microsoft Entra: sign-in log activity details — 認証詳細、相関用の識別子、IPや時刻の解釈。
• Microsoft Entra: sign-in logs — 対話型・非対話型などのログの種類。
• OWASP Logging Cheat Sheet — ログの項目、除外すべき秘密情報、保護の考え方。
• RFC 5737 — 本練習で使う文書用IPv4アドレスの範囲。