NeoShield Security Quantum X 無料診断

// 診断方法

Webサイト診断の仕組み

NeoShield は、診断の許可を得たWebサイトについて、公開側のセキュリティ設定を診断します。このページでは、何を確認するのか、結果をどう採点・確認するのか、どこに限界があるのかを説明します。

1. まず許可を確認

診断のたびに、Webサイトの所有者であるか、診断の許可を得ていることを確認していただきます。定期診断を作成するときも同様です。定期監視にはドメイン管理の証明（DNS TXT レコードまたはWebサイト上のファイル）も必要で、毎週再確認します。

2. 確認すること

3. リクエストの送り方

診断では、訪問者がいくつかのページを開くのと同程度の、少数の通常の GET・HEAD リクエストを送り、公開 DNS レコードを読み取ります。詳細診断では、サーバーが受け付ける HTTP メソッドを確認するために OPTIONS リクエストを1回送ります。使うポートは 80 と 443 のみです。プライベート、内部、リンクローカル、クラウドのメタデータ、予約済みのアドレスへの接続は、リダイレクトや DNS 解決の後も含めてブロックします。

4. 重要度、スコア、カバー率

各確認には、その弱点で何ができてしまうかに基づく固定の重要度（重大、高、中、低、情報）があります。スコアを下げるのは確認済みの未解決の検出項目だけで、情報や要確認の項目は下げません。カバー率と確度は別に表示し、一部の確認が実行できなかった場合は評価に上限を設けるため、不完全な診断で最高評価になることはありません。

スコアは確認した設定をまとめたものです。セキュリティの格付け、認証、保証ではありません。

指摘の優先順位の付け方

未解決の指摘は重い順に並べ、重要度から修正の優先度を付けます。Critical は P0、High は P1、Medium は P2、Low は P3、情報は P4 です。同じ重要度の中では、すべての訪問者に影響するもの（HTTPS、HSTS）を、他の弱点があって初めて問題になるもの（CSP、Referrer-Policy）より先にします。重要度は一般的な公開サイトでその弱点が何を許すかを表すもので、個々のサイトのビジネス上の価値は考慮していません。顧客に合わせて順番を調整してください。

5. 修正のガイダンス

検出項目には、なぜ問題なのかと、Nginx、Apache HTTP Server、Microsoft IIS、Cloudflare、WordPress、AWS CloudFront の設定例が付きます。設定例は該当する場合にだけ表示します。設定例はあくまで出発点なので、まずステージング環境で試してください。 プラットフォーム別の修正ガイダンス

6. 修正確認と監視

修正確認では同じWebサイトを再診断し、各検出項目を「解決」「一部解決」「未解決」「確認できず」として記録します。解決と表示するのは診断で確認できた場合だけで、後の診断で再び見つかれば自動で未解決に戻ります。定期診断では毎回前回と比べ、検出項目を「新規」「改善」「悪化」「解決」として表示します。 修正確認の仕組み

7. AI による補助

任意の AI による優先順位付けでは、検出項目をわかりやすい言葉でまとめます。AI に渡すのは対象のホスト名、スコア、検出項目の文章だけで、メールアドレスや IP アドレスは渡しません。AI の出力は誤ることがあるため、対応する前にお客様ご自身で確認してください。NeoShield がレポートを1件ずつ人手で確認することはありません。

8. 確認しないこと

9. 参照している標準と資料

各チェックは公開されたガイダンスに基づいており、レポートでは該当する CWE、RFC、NIST の参照を指摘の横に記載します。主な参照先は次のとおりです。

診断で参照している標準と資料
参照先用途
OWASP Secure Headers Project想定すべき HTTP レスポンスヘッダーと推奨値。
Mozilla Web Security GuidelinesHTTPS、HSTS、CSP、Cookie、フレーム、Referrer-Policy の基本設定。
NIST Cybersecurity Framework 2.0指摘は Protect 機能のプラットフォームとデータのセキュリティに関わり、監視は Detect を支えます。NeoShield は CSF への適合性は評価しません。
CIS Critical Security Controls v8安全な構成（Control 4）、通信の暗号化（Safeguard 3.10）、DMARC を含むメールの保護（Control 9）。NeoShield が確認するのは公開されたいくつかの兆候で、コントロールそのものではありません。
RFC 6797: HTTP Strict Transport SecurityHSTS ヘッダーと max-age、includeSubDomains の仕組み。
RFC 9116: security.txtWeb サイトのセキュリティ連絡先ファイルの形式と場所。
RFC 7208: SPFSPF レコードの書式と DNS 参照10回の上限。
RFC 7489: DMARCDMARC レコードの書式、ポリシー、レポート。

これらは、各チェックの根拠を示すためのものです。NeoShield や診断対象の Web サイトが、これらの組織や標準による認証を受けている、準拠している、推奨されているという意味ではありません。NeoShield は SOC 2 や ISO/IEC 27001 の認証を取得していません。

10. 開発者向けと顧客向けの指摘の説明

レポートは、変更を行う開発者と、それを承認して費用を負担する顧客の両方に伝わる必要があります。よくある指摘を、それぞれの立場に合わせて説明します。

HTTP Strict Transport Security（HSTS） 未設定時の重要度：高

開発者向け
Strict-Transport-Security レスポンスヘッダーは、max-age 秒の間このホストには HTTPS だけを使うようブラウザーに指示します。これがないと、訪問者が平文の HTTP で送る最初のリクエストが、HTTPS へのリダイレクト前に傍受されたりダウングレードされたりするおそれがあります。HTTPS のレスポンスに設定し、短い max-age から始めて6か月以上に引き上げてください。includeSubDomains は、すべてのサブドメインが HTTPS で動くことを確認してから追加します。
顧客向け
ブラウザーに対して、常に安全な版のサイトを使うよう指示していません。公衆 Wi-Fi などでは、訪問者が気づかないうちに安全でないページに誘導される可能性があります。修正はサーバー設定1行です。

参照： RFC 6797 · OWASP Secure Headers · Mozilla Web Security Guidelines

Content-Security-Policy（CSP） 未設定時の重要度：中

開発者向け
CSP は、ページがスクリプト、スタイル、フレームなどを読み込んでよい場所を指定します。ポリシーが適用されていないと、（脆弱なプラグインなどから）注入されたスクリプトがブラウザー側で何の制限もなく動きます。まず Content-Security-Policy-Report-Only で違反を集め、その後に適用してください。CSP がないことは、サイトにクロスサイトスクリプティングの脆弱性があることの証明ではありません。二重の防御策です。
顧客向け
どのプログラムの実行を許すかを、サイトがブラウザーに伝えていません。万一、攻撃者がページにプログラムを紛れ込ませた場合、訪問者のブラウザーでの実行を止めるものがありません。厳しいポリシーはサイトの一部を壊すことがあるため、導入にはテストが必要です。

参照： OWASP Secure Headers · Mozilla Web Security Guidelines · CWE-693

クリックジャッキング対策 未設定時の重要度：中

開発者向け
CSP の frame-ancestors も X-Frame-Options も確認できなかったため、どのサイトでもこのページを iframe で読み込めます。攻撃者はフレームを重ねて、ログイン中の訪問者に本物のボタンを押させることができます。CSP で frame-ancestors 'self'（推奨）または X-Frame-Options: SAMEORIGIN を設定してください。
顧客向け
別の Web サイトがこのサイトを自分のページの中に隠して表示し、「確定」や「削除」など、見えないボタンを押させることができます。サーバー設定1つで防げます。

参照： OWASP Secure Headers · Mozilla Web Security Guidelines · CWE-1021

Cookie のセキュリティ属性 未設定時の重要度：中

開発者向け
セッション用と思われる Cookie に、Secure（平文の HTTP で送信される）、HttpOnly（JavaScript から読める）、SameSite（クロスサイトのリクエストで送信される）のいずれかが設定されていません。セッションや認証の Cookie には3つすべてを設定してください。重要でないと思われる Cookie は、用途をスキャナーが判断できないため、確認用の低重要度項目として報告します。
顧客向け
サイトのログイン用 Cookie に標準的な保護が設定されていないため、ログイン中のセッションを盗まれたり、他のサイトから悪用されたりしやすくなっています。修正はサイトまたはプラットフォームの設定変更です。

参照： OWASP Secure Headers · Mozilla Web Security Guidelines · CWE-614 · CWE-1004

Referrer-Policy 未設定時の重要度：低

開発者向け
明示的な Referrer-Policy が確認できませんでした。主要な最新ブラウザーは既定で strict-origin-when-cross-origin を使いますが、古いブラウザーや組み込みブラウザーは、トークンや検索語を含むことがある完全な URL を他のサイトに送る場合があります。明示的なポリシーで、どこでも同じ動作になります。strict-origin-when-cross-origin または no-referrer を設定してください。
顧客向け
一部のブラウザーでは、訪問者が他のサイトへのリンクをたどると、直前に見ていたページの完全なアドレスがそのサイトに伝わることがあります。最新のブラウザーの多くはすでに制限しています。リスクは低く、サーバー設定1つで修正できます。

参照： OWASP Secure Headers · Mozilla Web Security Guidelines · CWE-200

SPF（Sender Policy Framework） 未設定時の重要度：中

開発者向け
ドメインに SPF の TXT レコードがないため、受信側のメールサーバーは、どのサーバーがこのドメインのメールを送ってよいかを確認できません。正規の送信元（メールサーバー、メールマガジン、請求書サービスなど）をすべて記載したレコードを1つ公開し、最初は ~all、確認後は -all で終えてください。DNS 参照は10回以内に収めます。
顧客向け
このドメインのメールを送ってよいサービスが宣言されていません。そのため、会社を装った偽の請求書やパスワード再設定メールを、本物らしく送られやすくなっています。

参照： RFC 7208 · NIST SP 800-177 · CIS Controls v8 (Control 9)

DMARC 未設定時の重要度：中

開発者向け
_dmarc の TXT レコードが見つかりませんでした。DMARC は、SPF と DKIM の整合に失敗したメールの扱いと、レポートの送り先を受信側に伝えます。まず rua の宛先付きで v=DMARC1; p=none を公開してレポートを確認し、正規の送信元が整合したら p=quarantine、p=reject に進めてください。
顧客向け
会社の名前を使った偽メールをどう扱うかについて、会社からメール事業者への指示がないため、各事業者が独自に判断しています。設定すると、会社の名前でメールを送っている送信元が分かり、やがて偽メールをブロックしてもらえるようになります。

参照： RFC 7489 · NIST SP 800-177 · CIS Controls v8 (Safeguard 9.5)

よくある質問

これはペネトレーションテストですか？

いいえ。受動的な設定診断です。攻撃、ログイン、総当たり、ファジングは行わず、アプリケーションのロジックや認証が必要な領域も確認しません。

検出項目は NeoShield の担当者が確認していますか？

いいえ。検出項目は自動の確認から生成され、任意の AI がその要約を作ります。対応したり顧客にレポートを送ったりする前に、証拠をお客様ご自身で確認してください。

スコアが高ければ安全ということですか？

いいえ。スコアは確認した公開側の設定をまとめたものです。問題が見つからなくても、脆弱性がないことの証明にはなりません。

サンプルレポートをすべて見る 許可を得た1サイトを無料で診断