免費諮詢
SECURITY QUICK CHECK

找出公開設定的弱點，並梳理接下來應確認的風險。

從網域的公開資訊中，快速確認 HTTPS、DNS、安全標頭等基本設定。此外，也用易懂的圖示梳理僅憑公開設定無法發現的憑證、權杖、雲端、端點與備份風險。

此檢查是僅使用公開資訊的非侵入式簡易確認。不進行內部滲透測試、密碼嘗試、連接埠掃描或應用程式的詳細弱點診斷。

免費檢查網域 諮詢安全改善
以公開資訊為主進行確認 無需輸入密碼或機密資訊 無入侵或暴力破解嘗試 結果並非安全保證，而是改善的起點
零信任設計

不再默認「內網就安全」——零信任的防護方式

對外可見的入口狀態可透過本次簡易診斷確認。再往內，則由「零信任」來防護——無論在公司、雲端還是在家，每次存取都驗證使用者與裝置。

  • 身分與多因素驗證

    以 Microsoft Entra 強化身分驗證。擺脫僅靠密碼，透過多因素驗證與條件式存取阻止非法登入。

  • 裝置健康狀態

    只信任公司掌握並管理的裝置。檢查系統更新與反惡意軟體狀態，阻斷來自高風險裝置的存取。

  • 最小權限與可視化

    只授予每個人所需的範圍。記錄並可視化誰存取了什麼，以便快速發現異常。

即使生成式 AI 與外部整合（MCP、API）不斷增加，因為靠「驗證」而非網路邊界來防護，擴展時也不易出現新的缺口。

諮詢零信任設計

攻擊者盯上的不只是密碼

認證成功後簽發的 Cookie 與存取權杖、應用與 CI/CD 持有的機密、雲端工作負載的身分、認證平台的簽章金鑰，都會成為攻擊目標。因此，除了入口認證，還需從整體思考「憑證存在於何處、可能從何處被帶走」。

點擊圖片可放大檢視

混入 URL 與日誌

若在 URL 中包含存取權杖，會殘留在瀏覽器歷史、Referer、代理、APM、存取日誌等處。

應用／API 伺服器遭入侵

伺服器一旦被入侵，可能從記憶體、快取、資料庫、設定檔等處取得權杖與機密。

CI/CD 與原始碼管理

API 金鑰、密碼、權杖可能被誤記錄到環境變數、建置日誌、設定檔與原始碼中。

憑證並非只存在於一處。在 URL、瀏覽器、伺服器、雲端、開發流水線與端點等各處，都需要「不暴露、不殘留、不擴散」的設計。

依攻擊路徑分類的詳細解說

我們將典型攻擊整理為五個類別。每張圖片皆可點擊或輕觸放大。

認證與工作階段

釣魚／中繼型攻擊

透過偽造郵件或連結，將使用者誘導至偽造登入頁面。中繼伺服器可介於使用者與正規服務之間，將帳號、密碼乃至 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 與惡意瀏覽器擴充功能

若惡意 JavaScript 混入 Web 應用並執行，可能讀取 localStorage、sessionStorage、畫面輸入及可讀 Cookie，並傳送到外部。

查看攻擊流程與對策
攻擊流程

使用者安裝的惡意擴充功能也可能存取頁面內容、表單資訊、Cookie 與權杖。

可能的影響

可能從已登入使用者處帶走認證權杖與輸入資訊，導致冒充或資訊外洩。

優先對策
  • 不要停用 Razor 自動編碼
  • 不要隨意使用 Html.Raw
  • 避免 innerHTML 與 document.write
  • 如需允許 HTML，使用可信的清洗器
  • 以 nonce 或 hash 方式設定 CSP
  • 為 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 減少固定憑證
  • 分離應用、資料庫與管理面
  • 實施最小權限 RBAC
  • 部署 EDR、日誌監控與異常偵測
  • 準備遭入侵時的機密輪換流程
Quick Check 可發現的範圍

伺服器內部狀態無法從公開資訊確認。僅可確認對外公開的 HTTPS 與部分標頭。

Quick Check 無法發現的範圍

無法確認機密管理方式、權限設計、修補程式套用、EDR 與監控部署以及工作負載隔離。

雲端工作負載遭入侵與 Managed Identity 濫用

攻擊者侵入 Web 應用、VM、App Service 或容器，存取內部中繼資料服務或認證端點。

查看攻擊流程與對策
攻擊流程

取得分配給工作負載的 Managed Identity 等臨時存取權杖，冒充應用存取 Azure 資源。

可能的影響

Managed Identity 本身是有效機制，但若工作負載遭入侵且該身分被賦予過多權限，攻擊者也能取得同樣的權限。

優先對策
  • 對 Managed Identity 也套用最小權限
  • 不要隨意授予訂用帳戶級 Contributor
  • 不要在無關的多個工作負載間共享同一身分
  • 不要讓外部輸入驅動任意外發 URL
  • 使用 URL 白名單並驗證解析後的 IP
  • 拒絕私有、回環與連結本地目標
  • 對重新導向目標也重新驗證
  • 考慮網路隔離與 Private Endpoint
Quick Check 可發現的範圍

雲端內部的權限與網路設計無法從公開資訊確認。

Quick Check 無法發現的範圍

無法確認 Managed Identity 權限設計、SSRF 防禦、網路隔離以及中繼資料服務保護情況。

注意 不要僅用簡單的字串檢查來實現 SSRF 防禦。需要驗證解析後的 IP，並在每次重新導向時重新驗證。

持續評估整個雲端的弱點與攻擊路徑

在生成式 AI 與攻擊自動化使「發現弱點到發起攻擊」的時間縮短的背景下，用 Microsoft Defender for Cloud 持續評估雲端安全態勢的理念。

查看攻擊流程與對策
攻擊流程

對資產、設定與弱點進行持續評估，掌握暴露在網際網路的資產，進行貫穿身分、網路與資料的攻擊路徑分析，並管理含 Azure、AWS、GCP 的多雲。

可能的影響

不是以相同優先級修復所有問題，而是結合暴露面、權限、弱點、資料重要性與真實攻擊路徑來排定優先級。

優先對策
  • 盤點資產與已連接環境
  • 確認 Defender for Cloud 覆蓋範圍
  • 為安全建議指定負責人與期限
  • 依攻擊路徑優先處理高風險項
  • 定期檢查網際網路暴露資產
  • 記錄例外、豁免與未處理原因
  • 在管理層、資訊部門與開發間共享進展
Quick Check 可發現的範圍

此簡易檢查僅能發現部分公開資產（如 HTTPS、DNS）。

Quick Check 無法發現的範圍

無法確認雲端設定的全面評估、攻擊路徑分析、Defender 覆蓋範圍與優先級排定。

注意 產品功能與名稱可能更新，請以 Microsoft Learn 最新資訊為準進行確認。

端點與管理員

使用端點的惡意軟體

展示已登入業務應用或雲端服務的端點被惡意軟體入侵的過程。

查看攻擊流程與對策
攻擊流程

從被入侵的端點可能竊取瀏覽器保存的帳號密碼、執行行程記憶體、Cookie 與權杖、快取與暫存檔、畫面與輸入資訊。

可能的影響

即便認證很強，若用於登入的端點本身遭入侵，登入後的憑證仍可能被竊取。對於重要操作或管理員工作，需將端點安全作為認證條件的一部分。

優先對策
  • 部署 EDR 並檢查是否有端點未納管
  • 套用攻擊面縮減規則
  • 透過條件式存取要求受管／合規端點
  • 削減本機管理員權限
  • 實施應用程式控制
  • 使用管理員專用端點（PAW／SAW）
  • 準備感染端點隔離與權杖撤銷流程
Quick Check 可發現的範圍

端點狀態完全無法從公開資訊確認。

Quick Check 無法發現的範圍

無法確認 EDR 部署、端點合規、條件式存取、本機管理員權限與應用控制情況。

復原與備份

遭入侵後仍可復原的不可變備份

將來自 Azure 與本地環境的備份保存到受保護區域，並由中央 Immutable Vault 在保留期內使其不可刪除、不可竄改。

查看攻擊流程與對策
攻擊流程

即便攻擊者或被入侵的管理員試圖刪除備份、刪除復原點、縮短保留期或停用保護，縱深防禦也會保護這些關鍵操作。

可能的影響

在勒索軟體防護中，不僅要保護生產資料，還需保護備份本身免受攻擊者與被入侵管理員的破壞。

優先對策
  • 在受支援的保存庫上啟用不可變性
  • 運行穩定後考慮 Locked 狀態
  • 啟用軟刪除
  • 設定 Resource Guard 與多使用者授權（MUA）
  • 分離備份管理員與安全管理員
  • 將 Resource Guard 置於獨立訂用帳戶或獨立租戶
  • 定期執行復原測試
  • 依業務需求設定 RPO、RTO 與保留期
Quick Check 可發現的範圍

備份與復原設計無法從公開資訊確認。

Quick Check 無法發現的範圍

無法確認保存庫設定、不可變性、軟刪除、MUA、職責分離與復原測試情況。

注意 此圖為概念圖。並非所有 Azure 資料庫或本地產品只要開啟設定就能以相同方式受保護。可用功能因受支援的工作負載、保存庫類型、區域與方式而異，需在實際環境中確認。

不知從何入手時，用五個階段來梳理

無需一次性處理所有問題。思路是按「影響大且易被利用」的順序逐步整改。

  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 與認證審查

  • 設計 MFA 與條件式存取
  • 審視管理員權限與 PIM/JIT
  • 梳理來賓與外部協作權限
  • 制定登入風險應對方針

Azure 與多雲審查

  • 持續評估雲端態勢的思路
  • 掌握暴露資產與攻擊路徑
  • 審視權限、網路與資料保護
  • 排定優先級的改進路線圖

應用與開發流程審查

  • 設計輸入校驗與輸出轉義
  • 密鑰管理與設定資訊處理
  • 檢查相依與供應鏈
  • 將安全嵌入開發流程

勒索軟體與復原設計

  • 設計不可變備份
  • 備份治理與職責分離
  • 復原測試與復原流程
  • 設定 RPO/RTO 與保留策略
就檢查結果諮詢 預約 30 分鐘安全諮詢

審查內容會依環境與規模調整。請先告訴我們現狀與關心的問題。

簡易檢查可確認的範圍

此檢查可確認的內容

以下僅顯示目前後端實作實際確認的項目。

  • 是否透過 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 的權限設計
  • 使用端點的惡意軟體感染
  • 簽章金鑰與憑證的管理狀況
  • 備份的抗刪除能力
  • 內部網路或管理介面的設定

確認公開設定只是「入口」。對於重要系統，需要將應用、身分、雲端、端點與備份組合起來評估。

先確認已公開的設定

從網站外部可確認的設定中，隱藏著防禦攻擊的重要線索。但公開設定沒有問題，並不等於整個系統是安全的。

以 example.com 的格式輸入 無需輸入 http://、https:// 或路徑 請輸入貴司擁有或有權確認的網域

常見問題

僅憑這個簡易檢查就能說我們的安全沒問題嗎？

不能。此診斷僅檢查網域的公開入口部分（HTTPS、DNS、郵件認證等），不涵蓋認證平台、雲端設定、端點、內部系統與備份。它並非安全保證，請將其視為發現問題的第一步。

我輸入的網域會被保存嗎？

本工具不會將您輸入的網域持久保存到資料庫等。它僅為診斷臨時連線目標網域並顯示結果。結果頁面的 URL 中也不包含該網域。

可以檢查非本公司管理的網域嗎？

本工具在公開資訊範圍內進行外部檢查，但原則上請對您擁有或獲授權的網域使用。它並非用於對他人網域進行過度探測或攻擊性行為。

顯示「無問題」的項目今後也安全嗎？

這只是當時的外部檢查結果。憑證到期、設定變更與新弱點都會改變狀況。請以定期複查與持續監控維運為前提。

頁面上的圖示與產品名稱可以直接套用到本公司嗎？

圖示為傳達思路的概念圖。實際可用的功能與設定取決於工作負載、授權、區域與設定。採用前請以最新官方資訊並在自身環境中確認。

如果想諮詢改進，應從何入手？

請先告訴我們本頁的簡易檢查結果與您的顧慮。我們會結合您的現狀，一起梳理應從發布設定、認證、雲端、應用還是復原入手。歡迎透過諮詢表單或預約諮詢與我們聯繫。