公開設定の弱点を見つけ、次に確認すべきリスクまで整理。

ドメインの公開情報から、HTTPS、DNS、セキュリティヘッダーなどの基本設定を短時間で確認します。さらに、公開設定だけでは発見できない認証情報・トークン・クラウド・端末・バックアップのリスクも、分かりやすい図で整理します。

このチェックは、公開情報を利用した非侵入型の簡易確認です。内部への侵入試験、パスワード試行、ポートスキャン、アプリケーションの詳細な脆弱性診断は行いません。

公開情報を中心に確認 パスワードや秘密情報の入力不要 侵入・総当たり試行なし 結果は安全保証ではなく改善の入口

「社内だから安全」をやめる ― ゼロトラストという守り方

外から見える入口の状態は、この簡易診断で確認できます。その先は、社内・クラウド・在宅を問わず、アクセスのたびに本人と端末を検証する「ゼロトラスト」で守ります。

  • ID・多要素認証

    Microsoft Entra で本人確認を徹底。パスワード頼みをやめ、多要素認証と条件付きアクセスで不正ログインを防ぎます。

  • デバイスの健全性

    会社が把握・管理する端末だけを信頼。OS更新やマルウェア対策の状態を確認し、危険な端末からのアクセスを遮断します。

  • 最小権限と可視化

    必要な人に必要な範囲だけを許可。誰が何にアクセスしたかを記録・可視化し、異常をすぐ検知できるようにします。

生成AIや外部連携(MCP・API)が増えても、境界ではなく"検証"で守るため、拡張しても穴が広がりにくいのが利点です。

ゼロトラスト設計を相談する

攻撃者が狙うのは、パスワードだけではありません

認証が成功した後に発行されるCookieやアクセストークン、アプリやCI/CDが持つ秘密情報、クラウドワークロードのID、認証基盤の署名鍵も攻撃対象になります。そのため、入口の認証だけでなく、「どこに認証情報が存在し、どこから持ち出されるか」を全体で考える必要があります。

画像をクリックすると拡大表示します

URL・ログへの混入

URLにアクセストークンを含めると、ブラウザ履歴、Referer、プロキシ、APM、アクセスログなどへ残ります。

アプリ/APIサーバー侵害

サーバーへ侵入されると、メモリ、キャッシュ、データベース、設定ファイルなどからトークンや秘密情報を取得される可能性があります。

CI/CD・ソース管理

APIキー、パスワード、トークンが、環境変数、ビルドログ、設定ファイル、ソースコードへ誤って記録される可能性があります。

認証情報は一か所だけに存在するわけではありません。URL、ブラウザ、サーバー、クラウド、開発パイプライン、端末のそれぞれで「見せない・残さない・広げない」設計が必要です。

攻撃経路別の詳しい解説

代表的な攻撃を5つのカテゴリーに整理しました。各画像はクリックまたはタップで拡大できます。

認証とセッション

フィッシング/中継型攻撃

偽メールや偽リンクから、利用者を偽のログイン画面へ誘導します。中継サーバーが利用者と正規サービスの間に入り、ID・パスワードやMFA操作を正規サービスへ中継する場合があります。

攻撃の流れと対策を見る
攻撃の流れ

正規サービス側でログインが成功すると、成立したセッションCookieや認証トークンを攻撃者が取得し、ログイン済み状態を再利用する可能性があります。

想定される影響

MFAを導入していても、方式によっては中継型フィッシングの影響を受け、ログイン済みセッションを乗っ取られる可能性があります。

優先対策
  • 管理者や重要ユーザーからパスキー/FIDO2へ移行
  • レガシー認証の無効化
  • 条件付きアクセスの適用
  • 準拠端末や管理対象端末を要求
  • 不審なサインインとセッションを監視
  • セッション失効手順を準備
Quick Checkで分かる範囲

公開情報からは、メールやログイン画面の中身までは確認できません。HTTPSやHSTSの有無など、基本設定の一部のみ確認できます。

Quick Checkでは分からない範囲

MFAの方式、条件付きアクセス、セッション保護、フィッシング耐性認証の導入状況は確認できません。

注意 「FIDO2を入れれば全攻撃を防げる」とは考えないでください。端末自体が侵害された場合や、ログイン後のセッション窃取には別の防御が必要です。

認証基盤・署名鍵侵害

攻撃者が認証基盤、署名鍵、証明書、鍵管理サーバー、管理者アカウントなどへ侵入します。

攻撃の流れと対策を見る
攻撃の流れ

署名用の秘密鍵を取得または不正利用すると、本物の認証基盤が発行したように見えるJWTやトークンを生成し、API、業務アプリ、クラウドリソースへアクセスできる可能性があります。

想定される影響

署名鍵は認証の信頼を支える土台です。侵害されると、パスワードを盗まなくても正規に見えるトークンを作られる可能性があります。

優先対策
  • 高価値の署名鍵をHSMまたはManaged HSMで保護
  • 制御プレーンとデータプレーンの権限を分離
  • 認証基盤管理、鍵管理、監査の役割を分離
  • PIMやJITで管理権限を一時化
  • 定期的な鍵ローテーション
  • 鍵失効・証明書更新・トークン無効化の緊急手順
  • 本番鍵を開発環境へ持ち込まない
Quick Checkで分かる範囲

認証基盤や鍵の管理状況は公開情報からは確認できません。

Quick Checkでは分からない範囲

署名鍵の保護方式(HSM等)、権限分離、鍵ローテーション、監査ログ、緊急失効手順は確認できません。

注意 HSMだけで管理者アカウント侵害や不正な鍵利用をすべて防げるわけではありません。管理分離と監視を組み合わせてください。

Webアプリとログ

XSS・悪意あるブラウザ拡張機能

Webアプリへ悪意あるJavaScriptが混入して実行されると、localStorage、sessionStorage、画面上の入力、参照可能なCookieなどを読み取り、外部へ送信される可能性があります。

攻撃の流れと対策を見る
攻撃の流れ

利用者がインストールした悪意ある拡張機能も、ページ内容、フォーム情報、Cookie、トークンなどへアクセスできる場合があります。

想定される影響

ログイン済みの利用者から、認証トークンや入力情報が持ち出され、なりすましや情報漏えいにつながる可能性があります。

優先対策
  • Razorの自動エンコードを無効化しない
  • Html.Rawを安易に使用しない
  • innerHTMLやdocument.writeを避ける
  • HTMLを許可する場合は信頼できるサニタイザーを使用
  • CSPをnonceまたはhashベースで設定
  • CookieへHttpOnly、Secure、適切なSameSiteを設定
  • 認証トークンをlocalStorageへ安易に保存しない
  • 企業端末ではブラウザ拡張機能を許可制にする
Quick Checkで分かる範囲

Content-Security-PolicyやX-Content-Type-Optionsヘッダーの有無は確認できます(多層防御の一部)。

Quick Checkでは分からない範囲

実際にXSSが存在するか、Cookie属性(HttpOnly / Secure / SameSite)、トークンの保存先、拡張機能の管理状況は確認できません。

注意 CSPは重要ですが、XSS対策の中心にしないでください。基本は入力値の検証、出力先に応じたエンコード、安全なDOM APIの利用です。HttpOnly CookieはXSSそのものを修正するものではありません。

URL・ログへの秘密情報の混入

ログイン後のURLにaccess_tokenなどの秘密情報を含めると、ブラウザ履歴、Referer、リバースプロキシ、APM、Webサーバーのアクセスログなどへ残る可能性があります。

攻撃の流れと対策を見る
攻撃の流れ

ログへ残ったトークン、認可コード、セッションID、ユーザー識別子などが閲覧・転送され、不正利用される可能性があります。

想定される影響

URLは多くのシステムに記録されます。POST本文であってもAPMやデバッグログへ記録される場合があり、「POSTなら必ず安全」とは言えません。

優先対策
  • URLへ秘密情報を載せない
  • ログ取得前にトークンやCookieをマスキング
  • APM、プロキシ、WAF、アクセスログの設定を確認
  • Referrer-Policyを設定
  • トークンを短命化
  • 不要なクエリ文字列を分析基盤へ送らない
Quick Checkで分かる範囲

URLの設計やログの中身は外部から確認できません。基本的なセキュリティヘッダーの有無のみ確認できます。

Quick Checkでは分からない範囲

URLへの秘密情報混入、ログのマスキング状況、APMやプロキシの設定、Referrer-Policyの内容は確認できません。

クラウドとサーバー

アプリ/APIサーバー侵害

攻撃者が脆弱性、設定不備、不正アクセスなどを利用してアプリまたはAPIサーバーへ侵入し、内部を探索します。

攻撃の流れと対策を見る
攻撃の流れ

プロセスメモリ、キャッシュ、データベース、環境変数、設定ファイル、一時ファイル、ログなどから、トークン、Cookie、APIキー、接続文字列を取得し、別システムへ不正アクセスします。

想定される影響

アプリが正規に利用している認証情報も攻撃者から見えるため、「侵入させない」だけでなく、侵入されても秘密を見せず、権限を広げず、持ち出しを検知する設計が必要です。

優先対策
  • 秘密情報をソースや設定ファイルへ直接保存しない
  • Azure Key Vaultなどの秘密管理基盤を利用
  • Managed Identityで固定資格情報を減らす
  • アプリ、DB、管理系を分離
  • 最小権限のRBAC
  • EDR、ログ監視、異常検知
  • 侵害時のシークレットローテーション手順を準備
Quick Checkで分かる範囲

サーバー内部の状態は公開情報からは確認できません。外部公開されているHTTPSやヘッダーの一部のみ確認できます。

Quick Checkでは分からない範囲

秘密情報の管理方法、権限設計、パッチ適用、EDRや監視の導入状況、ワークロード分離は確認できません。

クラウドワークロード侵害とManaged Identityの悪用

攻撃者がWebアプリ、VM、App Service、コンテナーなどへ侵入し、内部のメタデータサービスや認証エンドポイントへアクセスします。

攻撃の流れと対策を見る
攻撃の流れ

ワークロードへ割り当てられたManaged Identityなどの一時的なアクセストークンを取得し、アプリになりすましてAzureリソースへアクセスします。

想定される影響

Managed Identity自体は有効な仕組みですが、ワークロードが侵害され、そのIDへ過剰な権限が与えられていると、攻撃者も同じ権限を利用できます。

優先対策
  • Managed Identityにも最小権限を適用
  • サブスクリプション全体のContributorなどを安易に付与しない
  • 無関係な複数ワークロードで同じIDを共有しない
  • 外部入力から任意URLへ接続させない
  • URLの許可リストと名前解決後IPの検証を実施
  • プライベート、ループバック、リンクローカル宛てを拒否
  • リダイレクト先も再検証
  • ネットワーク分離とPrivate Endpointを検討
Quick Checkで分かる範囲

クラウド内部の権限やネットワーク設計は公開情報からは確認できません。

Quick Checkでは分からない範囲

Managed Identityの権限設計、SSRF対策、ネットワーク分離、メタデータサービスの保護状況は確認できません。

注意 SSRF対策を単純な文字列チェックだけで実装しないでください。名前解決後のIP検証や、リダイレクトごとの再検証が必要です。

クラウド全体の脆弱性と攻撃経路を継続的に確認

生成AIや攻撃自動化によって、脆弱性の発見から攻撃開始までの時間が短くなる環境を背景に、Microsoft Defender for Cloudでクラウドのセキュリティ状態を継続的に評価する考え方です。

攻撃の流れと対策を見る
攻撃の流れ

資産・構成・脆弱性の継続評価、インターネット公開資産の把握、ID・ネットワーク・データを結んだ攻撃パス分析、Azure・AWS・GCPを含むマルチクラウド管理などを行います。

想定される影響

すべての問題を同じ優先度で直すのではなく、外部公開、権限、脆弱性、データの重要性、実際の攻撃経路を組み合わせて優先順位を付けます。

優先対策
  • 対象資産と接続済み環境の棚卸し
  • Defender for Cloudのカバレッジ確認
  • セキュリティ推奨事項の所有者と期限を設定
  • 攻撃パスから高リスク項目を優先
  • インターネット公開資産を定期確認
  • 例外・免除・未対応理由を記録
  • 改善状況を経営・情シス・開発で共有
Quick Checkで分かる範囲

この簡易チェックで分かるのは、公開資産の一部(HTTPSやDNSなど)のみです。

Quick Checkでは分からない範囲

クラウド構成の網羅的な評価、攻撃パス分析、Defenderのカバレッジ、優先順位付けは確認できません。

注意 製品機能や名称は更新される可能性があるため、Microsoft Learnの最新情報と矛盾しない範囲でご確認ください。

端末と管理者

利用端末のマルウェア

業務アプリやクラウドサービスへログインしている端末が、マルウェアによって侵害される流れを表しています。

攻撃の流れと対策を見る
攻撃の流れ

侵害された端末から、ブラウザ保存のID・パスワード、実行中プロセスのメモリ、Cookieや認証トークン、キャッシュや一時ファイル、画面や入力情報が盗まれる可能性があります。

想定される影響

認証が強固でも、ログインに使う端末自体が侵害されると、ログイン後の認証情報が盗まれる可能性があります。重要操作や管理者作業では、端末の安全性を認証条件の一部として扱う必要があります。

優先対策
  • EDRの導入とオンボード漏れの確認
  • 攻撃面の縮小ルール
  • 管理対象・準拠端末を条件付きアクセスで要求
  • ローカル管理者権限の削減
  • アプリケーション制御
  • 管理者専用端末(PAW/SAW)の利用
  • 感染端末の隔離とトークン失効手順
Quick Checkで分かる範囲

端末の状態は公開情報からは一切確認できません。

Quick Checkでは分からない範囲

EDRの導入、端末準拠、条件付きアクセス、ローカル管理者権限、アプリ制御の状況は確認できません。

復旧とバックアップ

侵害後も復旧できるイミュータブルバックアップ

Azureとオンプレミスの環境からバックアップを保護領域へ保存し、中央のImmutable Vaultで、保持期間中は削除・改ざんできない状態にする考え方です。

攻撃の流れと対策を見る
攻撃の流れ

攻撃者や侵害された管理者が、バックアップ削除、復旧ポイント削除、保持期間短縮、保護停止などを試みても、多層防御で重要操作を保護します。

想定される影響

ランサムウェア対策では、本番データを守るだけでなく、攻撃者や侵害された管理者からバックアップ自体を守る必要があります。

優先対策
  • 対応するVaultでイミュータビリティを有効化
  • 運用確定後にLocked状態を検討
  • Soft Deleteを有効化
  • Resource GuardとMUA(Multi-user Authorization)を構成
  • バックアップ管理者とセキュリティ管理者を分離
  • Resource Guardを別サブスクリプションまたは別テナントへ分離
  • 復元テストを定期実施
  • RPO・RTO・保持期間を業務要件から設定
Quick Checkで分かる範囲

バックアップや復旧の設計は公開情報からは確認できません。

Quick Checkでは分からない範囲

Vaultの設定、イミュータビリティ、Soft Delete、MUA、管理分離、復元テストの状況は確認できません。

注意 画像は概念図です。すべてのAzure DBやオンプレミス製品が設定するだけで同じ方式で保護されるわけではありません。対応ワークロード、Vault種別、リージョン、方式により利用可能な機能が異なるため、実環境での確認が必要です。

何から直すべきか分からない場合は、5段階で整理します

すべてを一度に対応する必要はありません。影響が大きく、悪用されやすいところから順番に整えていく考え方です。

  1. STEP 1 外部に公開している入口を守る

    • HTTPSの常時化とHTTP→HTTPSリダイレクト
    • TLS証明書の有効期限管理
    • HSTSなど基本セキュリティヘッダの付与
    • 不要な公開ポート・管理画面の閉鎖
  2. STEP 2 認証とアカウントを強くする

    • フィッシング耐性のある多要素認証
    • 条件付きアクセスで端末・場所・リスクを考慮
    • 管理者権限の最小化とPIM/JIT
    • 退職者・不要アカウントの整理
  3. STEP 3 アプリとデータの扱いを見直す

    • 入力値の検証と出力エスケープ(XSS対策)
    • 秘密情報をURLやログに残さない
    • シークレットをKey Vault等で管理
    • 最小権限でのAPI・サービス連携
  4. STEP 4 クラウドと端末を継続的に監視する

    • クラウド構成の継続評価と公開資産の把握
    • EDRの導入と端末の準拠状態
    • ログの集約と異常検知
    • インシデント対応手順の整備
  5. STEP 5 侵害されても復旧できる備えを持つ

    • 改ざん・削除に強いイミュータブルバックアップ
    • バックアップ管理者と本番管理者の分離
    • 定期的な復元テスト
    • RPO・RTOと保持期間を業務要件から設定

この順番はあくまで整理の目安です。実際の優先順位は、公開範囲、扱うデータの重要性、業務への影響によって変わります。

チェック結果を、実際の改善計画へ

簡易チェックはあくまで入口です。ここから先は、環境や運用に合わせて具体的な改善内容を一緒に整理します。

Web公開設定レビュー

  • HTTPS・TLS・セキュリティヘッダの点検
  • リダイレクトやCookie属性の確認
  • 不要な公開資産の洗い出し
  • 改善内容の具体化と優先順位付け

Entra ID・認証レビュー

  • 多要素認証と条件付きアクセスの設計
  • 管理者権限とPIM/JITの見直し
  • ゲスト・外部連携の権限整理
  • サインインリスクへの対応方針

Azure・マルチクラウドレビュー

  • クラウド構成の継続評価の考え方
  • 公開資産と攻撃経路の把握
  • 権限・ネットワーク・データ保護の見直し
  • 優先順位を付けた改善ロードマップ

アプリ・開発工程レビュー

  • 入力検証・出力エスケープの設計
  • シークレット管理と設定情報の扱い
  • 依存関係やサプライチェーンの確認
  • 開発工程へのセキュリティ組み込み

ランサムウェア・復旧設計

  • イミュータブルバックアップの設計
  • バックアップ管理と権限分離
  • 復元テストと復旧手順の整備
  • RPO・RTOと保持方針の設定

レビュー内容は環境や規模に合わせて調整します。まずは現状と気になっている点をお聞かせください。

簡易チェックで確認できる範囲

このチェックで確認できること

現在のバックエンド実装が実際に確認している項目のみを表示しています。

  • HTTPSで公開されているか
  • TLS証明書の有効期限
  • 主要なセキュリティヘッダー(HSTS / CSP / X-Content-Type-Options / X-Frame-Options)の有無
  • HTTPからHTTPSへの誘導(リダイレクト)
  • DNSの公開レコード(A / AAAA)
  • メール認証の公開設定(SPF / DMARC)

このチェックだけでは確認できないこと

  • アプリ内部の認可不備
  • SQLインジェクションやXSSの実検証
  • Entra IDや条件付きアクセスの設定
  • Cookie・トークンの保存方法
  • ソースコードやCI/CD内の秘密情報
  • サーバーのメモリやキャッシュ内の情報
  • Managed Identityの権限設計
  • 利用端末のマルウェア感染
  • 署名鍵や証明書の管理状況
  • バックアップの削除耐性
  • 内部ネットワークや管理画面の設定

公開設定の確認は「入口」です。重要システムでは、アプリ、ID、クラウド、端末、バックアップを組み合わせて評価する必要があります。

まずは公開されている設定を確認

Webサイトの外側から確認できる設定には、攻撃を防ぐための重要な手掛かりがあります。ただし、公開設定に問題がないことと、システム全体が安全であることは同じではありません。

example.com の形式で入力 http://、https://、パスは入力不要 自社または確認権限のあるドメインを入力してください

よくある質問

この簡易チェックだけで、自社のセキュリティは大丈夫と言えますか?

いいえ。この診断は、公開されているドメインの入口部分(HTTPSやDNS、メール認証など)を確認するものです。認証基盤、クラウド構成、端末、社内システム、バックアップなどは含まれません。安全性を保証するものではなく、あくまで最初の気づきのためのツールとお考えください。

入力したドメインは保存されますか?

このツールは、入力されたドメインをデータベースなどへ永続的に保存しません。診断のためにサーバーから対象ドメインへ一時的に接続し、結果を表示するために利用するだけです。診断結果の画面URLにもドメインは含まれません。

自社が管理していないドメインをチェックしてもよいですか?

このツールは、公開情報の範囲で外形的な確認を行うものですが、原則としてご自身が管理する、または許可を得たドメインでご利用ください。他者のドメインに対する過度な調査や攻撃的な行為は意図していません。

結果が「問題なし」だった項目は、今後も安全ですか?

その時点での外形的な確認結果にすぎません。証明書の期限、設定変更、新しい脆弱性などにより状況は変わります。定期的な確認と、継続的な監視・運用を前提としてお考えください。

掲載されている図や製品名は、そのまま自社に当てはめてよいですか?

図は考え方を伝えるための概念図です。実際に利用できる機能や設定は、対象のワークロード、契約、リージョン、構成によって異なります。導入前に、最新の公式情報とご自身の環境での確認をお願いします。

改善を相談したい場合、何から始めればよいですか?

まずはこのページの簡易チェック結果と、気になっている点をお知らせください。公開設定、認証、クラウド、アプリ、復旧のどこから着手すべきかを、現状に合わせて一緒に整理します。お問い合わせフォームや相談のご予約からお気軽にご連絡ください。