## Case #2: 防止 PUBLIC KEY 被掉包—內嵌與鎖固信任根

### Problem Statement（問題陳述）
業務場景：合作夥伴熟悉系統細節但拿不到私鑰，可能自生金鑰並替換給客戶的 PUBLIC KEY，讓客戶驗證假授權碼而不自知。
技術挑戰：如何確保客戶端驗證永遠針對原廠公鑰，而不被第三方置換。
影響範圍：所有客戶端驗證流程與更新機制；若被掉包，驗證毫無意義。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 公鑰以可替換檔案/設定下發，無驗證來源
2. 客戶端未固定（pin）信任根，允許任意公鑰
3. 更新/部署時無完整性校驗
深層原因：
- 架構層面：信任根未內建，缺乏單一來源
- 技術層面：未使用簽章/哈希鎖定公鑰
- 流程層面：第三方可單方對客戶下發關鍵檔

### Solution Design（解決方案設計）
解決策略：將原廠 PUBLIC KEY 以常數或資源內嵌於二進位檔，並對本體做完整性檢查；同時釘選（pin）公鑰指紋，所有外部更新/設定需以原廠簽章驗證才接受。

實施步驟：
1. 內嵌公鑰與指紋
- 實作細節：PEM 常數或資源檔，計算 SPKI 指紋
- 所需資源：編譯流程、代碼混淆工具
- 預估時間：0.5 週

2. 加入啟動時完整性檢查
- 實作細節：比較內建指紋與外部來源，拒絕不一致
- 所需資源：雜湊庫、啟動檢查模組
- 預估時間：0.5 週

3. 簽章的設定檔與外部資源
- 實作細節：只接受原廠簽章的更新包/設定檔
- 所需資源：簽章工具、驗證程式碼
- 預估時間：1 週

關鍵程式碼/設定：
```csharp
// 內嵌公鑰與 SPKI 指紋（pin）
const string VendorPublicKeyPem = @"-----BEGIN PUBLIC KEY-----
...base64...
-----END PUBLIC KEY-----";
const string VendorSpkiSha256 = "1b2f..."; // Base64 or hex

using var rsa = RSA.Create();
rsa.ImportFromPem(VendorPublicKeyPem);

// 驗證授權碼簽章
bool Verify(byte[] payload, byte[] signature)
{
    return rsa.VerifyData(payload, signature, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1);
}

## Case #3: 透過第三方 CA 分發信任—憑證鏈驗證授權碼

### Problem Statement（問題陳述）
業務場景：小型軟體商無法像遊戲主機一樣完全掌控客戶環境，需要可靠管道讓客戶取得正確的公鑰並驗證授權碼。
技術挑戰：防止公鑰掉包，同時支援跨網路、跨組織分發；兼顧成本與作業複雜度。
影響範圍：所有客戶驗證流程、更新與證書續約。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 沒有單一可信來源提供公鑰
2. 客戶端無法自行鑑別公鑰真偽
3. 憑證撤銷未檢查，風險延宕
深層原因：
- 架構層面：缺乏信任連結（Trust Chain）
- 技術層面：未使用 X.509/OCSP/CRL 機制
- 流程層面：證書續簽與分發流程不完整

### Solution Design（解決方案設計）
解決策略：採用公正第三方 CA 簽發之憑證承載公鑰；授權碼以該私鑰簽章，客戶端驗證憑證鏈與撤銷狀態，再以憑證公鑰驗簽授權碼。

實施步驟：
1. 申請企業憑證
- 實作細節：選擇 OV/EV，規劃期限與用途（Code Signing/Signing）
- 所需資源：CA 供應商、公司資料
- 預估時間：1-2 週

2. 客戶端驗證流程
- 實作細節：Build X509Chain，啟用 OCSP/CRL 檢查
- 所需資源：.NET X.509 API，網路可達性
- 預估時間：0.5 週

3. 授權碼簽章與發佈
- 實作細節：私鑰在 HSM/Key Vault，授權碼包含簽章與證書鏈
- 所需資源：簽章工具、格式定義
- 預估時間：1 週

關鍵程式碼/設定：
```csharp
// 驗憑證鏈 + 撤銷 + 驗授權碼簽章
X509Certificate2 vendorCert = LoadCertFromLicense(licenseBlob);
var chain = new X509Chain
{
    ChainPolicy =
    {
        RevocationMode = X509RevocationMode.Online,
        RevocationFlag = X509RevocationFlag.ExcludeRoot,
        VerificationFlags = X509VerificationFlags.NoFlag,
        UrlRetrievalTimeout = TimeSpan.FromSeconds(5)
    }
};

bool chainOk = chain.Build(vendorCert);
if (!chainOk) throw new SecurityException("Certificate chain invalid.");

using RSA rsa = vendorCert.GetRSAPublicKey();
bool sigOk = rsa.VerifyData(payload, signature, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1);

## Case #4: 自建企業 CA（封閉場域）—降低費用但保證可控

### Problem Statement（問題陳述）
業務場景：企業/專案在封閉網段或受控客戶內導入授權系統，需要可控且低成本的憑證分發與驗證，且客戶終端皆可受管理。
技術挑戰：如何安全地架設與維運 CA，並保證所有客戶都信任此 CA。
影響範圍：企業內所有授權驗證、更新與撤銷。
複雜度評級：高

### Root Cause Analysis（根因分析）
直接原因：
1. 公開 CA 成本高且續約管理繁瑣
2. 離線環境無法連外驗證
3. 根憑證分發與信任未管理
深層原因：
- 架構層面：缺少企業級 PKI
- 技術層面：沒有 OCSP/CRL 發佈與高可用
- 流程層面：未定義 CA 操作守則與稽核

### Solution Design（解決方案設計）
解決策略：部署 AD CS 或類似 PKI，將根 CA 離線保存、發佈中繼與簽發 CA；於客戶受控終端安裝根憑證；建立 OCSP/CRL 與稽核流程。

實施步驟：
1. 架設 CA
- 實作細節：離線根 CA、線上發證 CA、CRL/OCSP 發佈
- 所需資源：Windows AD CS/其他 PKI、隔離主機
- 預估時間：2-4 週

2. 終端信任佈建
- 實作細節：GPO/MDM 安裝根憑證，設定信任
- 所需資源：AD/MDM
- 預估時間：1 週

3. 流程與稽核
- 實作細節：簽發/撤銷 SOP、審批、審計
- 所需資源：流程系統、SIEM
- 預估時間：1 週

關鍵程式碼/設定：
```csharp
// 從 Windows 憑證存放區取出企業根/中繼 CA 並驗證鏈
var store = new X509Store(StoreName.Root, StoreLocation.LocalMachine);
store.Open(OpenFlags.ReadOnly);
bool trusted = store.Certificates.Cast<X509Certificate2>()
    .Any(c => c.Thumbprint?.Equals(expectedRootThumbprint, StringComparison.OrdinalIgnoreCase) == true);
store.Close();
if (!trusted) throw new SecurityException("Enterprise Root CA not trusted.");

## Case #5: 定期回連驗證（Call-Home/KMS-like）—降低掉包風險

### Problem Statement（問題陳述）
業務場景：無法使用 CA 或完整內嵌保護時，可透過定期連回原廠伺服器檢測授權，以阻斷被掉包公鑰的客戶環境。
技術挑戰：兼顧使用者體驗、離線寬限、隱私法規與可靠性。
影響範圍：所有終端的網路可用性與授權有效性。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 終端本地信任根可能被替換
2. 無法保證公鑰分發正確
3. 無中心化黑名單/撤銷能力
深層原因：
- 架構層面：缺少中心授權狀態
- 技術層面：沒有定期驗證與緩存策略
- 流程層面：未規範寬限與封鎖節點

### Solution Design（解決方案設計）
解決策略：實作啟用/續租模型（類似 Windows/KMS），終端定期回連取得簽章票據或續租 Token；若超過寬限期未回連則降級或鎖定高階功能。

實施步驟：
1. 啟用與續租 API
- 實作細節：/activate、/renew，返回短期簽章票據（JWT/JWS）
- 所需資源：授權伺服器、資料庫、TLS
- 預估時間：1 週

2. 客戶端排程與寬限
- 實作細節：每天嘗試、寬限 7-30 天、觀察策略
- 所需資源：排程器、儲存
- 預估時間：0.5 週

3. 異常偵測與黑名單
- 實作細節：同一序號超量使用、地理異常
- 所需資源：SIEM、告警
- 預估時間：1 週

關鍵程式碼/設定：
```csharp
// 續租流程
async Task<bool> TryRenewAsync(string deviceId, string licenseId)
{
    using var http = new HttpClient();
    var res = await http.PostAsJsonAsync(renewUrl, new { deviceId, licenseId, version = AppVersion });
    if (!res.IsSuccessStatusCode) return false;

    var token = await res.Content.ReadAsStringAsync();
    // 驗證伺服器公鑰簽章（內嵌或 CA 驗證）
    return VerifyServerToken(token);
}

## Case #6: 以「簽章更新包」作為強制驗證點

### Problem Statement（問題陳述）
業務場景：原廠透過定期發佈更新檔維護系統，要求只有通過「原廠簽章驗證」的環境才能安裝更新，藉此逼出未配置正確公鑰的環境。
技術挑戰：更新包簽章格式、驗證流程與回滾安全。
影響範圍：更新生命週期與客服支援。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 更新檔未簽章或客戶端不驗證
2. 更新流程允許第三方包注入
3. 無法阻斷未授權環境使用新功能
深層原因：
- 架構層面：更新未與授權驗證整合
- 技術層面：缺乏 PKCS#7/Authenticode 驗證
- 流程層面：未明確規範強制更新與回滾

### Solution Design（解決方案設計）
解決策略：更新包以原廠憑證簽章（PKCS#7/Authenticode），客戶端驗證簽章與證書鏈後才允許更新；關鍵功能只在足夠新版本啟用。

實施步驟：
1. 打包與簽章
- 實作細節：生成 .pkg/.zip + .p7s，或直接 Authenticode
- 所需資源：簽章憑證、打包工具
- 預估時間：0.5 週

2. 客戶端驗證
- 實作細節：驗證 CMS 簽章與鏈，拒絕未簽或未知簽章者
- 所需資源：.NET Pkcs API、X.509
- 預估時間：0.5 週

3. 回滾與鎖定策略
- 實作細節：禁止回滾到弱驗證版本
- 所需資源：版本策略
- 預估時間：0.5 週

關鍵程式碼/設定：
```csharp
// 驗證 PKCS#7 Detached 簽章（.p7s）
using System.Security.Cryptography.Pkcs;
using System.Security.Cryptography;

byte[] content = File.ReadAllBytes("update.pkg");
byte[] sig = File.ReadAllBytes("update.pkg.p7s");

var cms = new SignedCms(new ContentInfo(content), detached: true);
cms.Decode(sig);
cms.CheckSignature(verifySignatureOnly: true); // 同時可檢查鏈與撤銷

## Case #7: 離線啟用（Challenge-Response）—支援隔離網路

### Problem Statement（問題陳述）
業務場景：客戶在離線或高安隔離網路中部署，需要啟用授權但不可連外；仍需防止合作夥伴掉包公鑰。
技術挑戰：如何在不連網情況下建立一次性信任與綁定環境資訊。
影響範圍：離線客戶全體與維護流程。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 無法使用 CA/回連驗證
2. 環境資訊未綁定，易被複製
3. 手動流程易錯且不可稽核
深層原因：
- 架構層面：缺乏離線信任交換流程
- 技術層面：無挑戰/回應規格
- 流程層面：無人工驗證與紀錄機制

### Solution Design（解決方案設計）
解決策略：終端生成挑戰（含設備指紋/nonce/到期），由原廠以私鑰簽章回應；終端用內嵌公鑰驗證回應並啟用，支援人工載具（USB/QR）。

實施步驟：
1. 定義挑戰/回應格式
- 實作細節：JSON + Base64，包含 deviceId, nonce, exp
- 所需資源：格式定義、序列化
- 預估時間：0.5 週

2. 終端挑戰生成與驗證
- 實作細節：隨機數、防重放、到期檢查
- 所需資源：加密庫、儲存
- 預估時間：0.5 週

3. 原廠簽章工具
- 實作細節：離線簽章，產生授權回應檔
- 所需資源：簽章器、稽核
- 預估時間：1 週

關鍵程式碼/設定：
```csharp
record Challenge(string DeviceId, string Nonce, long Exp);
record Response(string ChallengeB64, string SignatureB64);

string CreateChallenge()
{
    var nonce = Convert.ToBase64String(RandomNumberGenerator.GetBytes(32));
    var c = new Challenge(GetDeviceId(), nonce, DateTimeOffset.UtcNow.AddHours(24).ToUnixTimeSeconds());
    return Convert.ToBase64String(System.Text.Json.JsonSerializer.SerializeToUtf8Bytes(c));
}

bool VerifyResponse(Response resp)
{
    byte[] challenge = Convert.FromBase64String(resp.ChallengeB64);
    byte[] signature = Convert.FromBase64String(resp.SignatureB64);
    using var rsa = RSA.Create(); rsa.ImportFromPem(VendorPublicKeyPem);
    return rsa.VerifyData(challenge, signature, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1);
}

## Case #8: 驗證邏輯防篡改—雙重驗證與完整性檢測

### Problem Statement（問題陳述）
業務場景：攻擊者可能藉由繞過或移除客戶端驗證程式碼（如打補丁）讓未簽章授權也能通過。
技術挑戰：如何增加繞過成本並能及時偵測篡改。
影響範圍：終端安全、品牌聲譽。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 驗證程式碼可被定位與移除
2. 可執行檔未做自檢
3. 未對關鍵路徑做冗餘驗證
深層原因：
- 架構層面：單點驗證
- 技術層面：缺乏自檢與反調試
- 流程層面：無紅隊測試與硬化需求

### Solution Design（解決方案設計）
解決策略：對授權驗證做雙路徑（不同模組/時間點）與啟動自檢（哈希/簽章）；失敗時降級功能與上報；結合代碼混淆。

實施步驟：
1. 自檢與簽章
- 實作細節：啟動對自身哈希/簽章比對
- 所需資源：雜湊庫、簽章工具
- 預估時間：0.5 週

2. 雙重驗證
- 實作細節：啟動與關鍵操作前各驗一次
- 所需資源：模組化驗證
- 預估時間：0.5 週

3. 反篡改與告警
- 實作細節：發現異常上報，啟用降級
- 所需資源：遙測/告警
- 預估時間：0.5 週

關鍵程式碼/設定：
```csharp
// 啟動自檢：比對已簽名的可執行檔哈希
bool SelfIntegrityCheck()
{
    var path = System.Diagnostics.Process.GetCurrentProcess().MainModule!.FileName!;
    var bytes = File.ReadAllBytes(path);
    var hash = Convert.ToHexString(SHA256.HashData(bytes));
    // expectedHash 可由原廠簽章的 manifest 提供或透過另一條驗證鏈取得
    return hash.Equals(expectedHash, StringComparison.OrdinalIgnoreCase);
}

## Case #9: 金鑰輪替與撤銷—多公鑰支援與 KeyId

### Problem Statement（問題陳述）
業務場景：長期運行中需定期輪替簽章私鑰或緊急撤銷，客戶端不得因換鑰而停擺。
技術挑戰：平滑切換、過渡期支援與舊授權兼容。
影響範圍：授權發放、客戶端驗證、更新與運維。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 授權格式未包含 KeyId
2. 客戶端僅認單一公鑰
3. 無撤銷與過渡期策略
深層原因：
- 架構層面：信任根單點
- 技術層面：未支援多鑰驗證
- 流程層面：無輪替時程與通知

### Solution Design（解決方案設計）
解決策略：授權碼包含 KeyId（kid），客戶端維護受信金鑰集合；推送新公鑰後逐步切換簽章；同時提供撤銷名單與最小支援版本。

實施步驟：
1. 擴充授權格式
- 實作細節：加入 kid 與簽章演算法標識
- 所需資源：格式版本管理
- 預估時間：0.5 週

2. 客戶端多鑰驗證
- 實作細節：以 kid 選擇公鑰，或 fallback 多鑰嘗試
- 所需資源：安全儲存、更新機制
- 預估時間：0.5 週

3. 輪替/撤銷計畫
- 實作細節：公告時程，雙簽過渡
- 所需資源：通訊、版本管控
- 預估時間：1 週

關鍵程式碼/設定：
```csharp
// kid -> RSA Public Key 對照
readonly Dictionary<string, RSA> TrustedKeys = new()
{
    ["k1"] = LoadRsaFromPem(Pem1),
    ["k2"] = LoadRsaFromPem(Pem2),
};

bool VerifyWithKid(string kid, byte[] data, byte[] sig)
{
    if (!TrustedKeys.TryGetValue(kid, out var rsa)) return false;
    return rsa.VerifyData(data, sig, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1);
}

## Case #10: 網路傳輸中的憑證釘選（Pinning）—避免中間人與錯誤公鑰

### Problem Statement（問題陳述）
業務場景：客戶端需從伺服器拉取更新或公鑰清單，若傳輸中被攔截或下發假憑證，可能導致公鑰掉包或惡意更新。
技術挑戰：在 TLS 之上實施釘選避免被替換。
影響範圍：所有線上更新/同步場景。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 單靠系統信任庫，可能信任錯誤中繼 CA
2. 無 SPKI/指紋釘選
3. 客戶端未對主機證書做額外驗證
深層原因：
- 架構層面：信任邊界過寬
- 技術層面：無二次驗證（pinning）
- 流程層面：憑證輪替未同步到客戶端

### Solution Design（解決方案設計）
解決策略：對伺服器端憑證做 SPKI 釘選（或中繼 CA 釘選），在 TLS 完成後自訂驗證回呼比對指紋；建立輪替期支援多枚釘選。

實施步驟：
1. 蒐集與管理指紋
- 實作細節：計算 sha256(PublicKeyInfo)
- 所需資源：工具、儲存
- 預估時間：0.5 週

2. 客戶端驗證回呼
- 實作細節：自訂 ServerCertificateCustomValidationCallback
- 所需資源：HttpClientHandler
- 預估時間：0.5 週

3. 釘選輪替
- 實作細節：支援舊新並存一段期間
- 所需資源：更新渠道
- 預估時間：0.5 週

關鍵程式碼/設定：
```csharp
var handler = new HttpClientHandler
{
    ServerCertificateCustomValidationCallback = (msg, cert, chain, errors) =>
    {
        var spki = cert.GetPublicKey();
        var hash = SHA256.HashData(spki);
        var pin = Convert.ToHexString(hash);
        return KnownPins.Contains(pin);
    }
};
var http = new HttpClient(handler);

## Case #11: 使用 TPM/可信平台保護信任根

### Problem Statement（問題陳述）
業務場景：在可控設備（自有硬體/OS）上，希望像遊戲主機般，將公鑰與驗證機制鎖進硬體與 OS，以抵抗高階攻擊。
技術挑戰：如何利用 TPM/KSP 將金鑰與驗證邏輯納入平台保護。
影響範圍：設備層面安全、維修成本。
複雜度評級：高

### Root Cause Analysis（根因分析）
直接原因：
1. 純軟體易被逆向與篡改
2. 公鑰/驗證程式缺乏硬體保護
3. 啟動鏈未驗證
深層原因：
- 架構層面：缺少可信啟動與度量
- 技術層面：未使用 TPM、Platform Crypto Provider
- 流程層面：韌體/OS 更新未簽章

### Solution Design（解決方案設計）
解決策略：在設備製造時將信任根燒錄/封裝；使用 TPM 與 Microsoft Platform Crypto Provider 產生不可匯出金鑰，OS 啟動過程度量，應用於執行時驗證授權碼。

實施步驟：
1. 平台金鑰生成
- 實作細節：CNG + Platform Crypto Provider
- 所需資源：TPM 2.0、Win10+
- 預估時間：1-2 週

2. 啟動度量與策略
- 實作細節：使用 Secure Boot/Measured Boot
- 所需資源：UEFI/OS 配置
- 預估時間：2 週

3. 應用整合
- 實作細節：從 Platform KSP 取得公鑰驗簽
- 所需資源：CNG API
- 預估時間：1 週

關鍵程式碼/設定：
```csharp
// 以 CNG 連結 Microsoft Platform Crypto Provider（示意）
var provider = new CngProvider("Microsoft Platform Crypto Provider");
var keyParams = new CngKeyCreationParameters
{
    Provider = provider,
    KeyUsage = CngKeyUsages.Signing,
    ExportPolicy = CngExportPolicies.None
};
using var key = CngKey.Create(CngAlgorithm.Rsa, "VendorKey", keyParams);
// 注意：平台金鑰通常不可匯出，僅可用於簽章/驗證

## Case #12: 授權碼簽章與驗證（.NET RSA-PSS/PKCS#1）

### Problem Statement（問題陳述）
業務場景：以數位簽章保護授權碼內容與完整性，確保不可偽造且可驗證。
技術挑戰：演算法選擇、序列化與跨平台相容。
影響範圍：所有授權碼生成與驗證。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 未簽章或簽章實作錯誤
2. 序列化導致資料不一致
3. 使用弱雜湊/不安全填充
深層原因：
- 架構層面：缺乏明確授權格式
- 技術層面：忽略演算法與參數
- 流程層面：無互通性測試

### Solution Design（解決方案設計）
解決策略：定義授權碼 canonical 序列化（JSON/CBOR），選擇 RSA-PSS+SHA-256 或 PKCS#1v1.5+SHA-256；提供清晰驗證 API 與測試向量。

實施步驟：
1. 內容序列化
- 實作細節：欄位排序與固定格式
- 所需資源：序列化庫
- 預估時間：0.5 週

2. 簽章/驗簽 API
- 實作細節：封裝 RSA 實作
- 所需資源：加密庫
- 預估時間：0.5 週

3. 測試向量
- 實作細節：跨語言驗證
- 所需資源：單元測試
- 預估時間：0.5 週

關鍵程式碼/設定：
```csharp
// 簽章
byte[] data = Encoding.UTF8.GetBytes(canonicalJson);
using var rsa = RSA.Create();
rsa.ImportFromPem(privateKeyPem);
byte[] sig = rsa.SignData(data, HashAlgorithmName.SHA256, RSASignaturePadding.Pss);

// 驗簽
using var vrsa = RSA.Create();
vrsa.ImportFromPem(publicKeyPem);
bool ok = vrsa.VerifyData(data, sig, HashAlgorithmName.SHA256, RSASignaturePadding.Pss);

## Case #13: 簽章器與發碼流程隔離—最小權限與雙人審批

### Problem Statement（問題陳述）
業務場景：授權碼生成涉及商業敏感資訊與關鍵私鑰操作，需降低內部濫用與誤操作風險。
技術挑戰：如何流程化與最小化權限。
影響範圍：內部運維與法遵。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 單一人員可直接生成大量授權
2. 簽章器與管理介面同機
3. 無審計紀錄
深層原因：
- 架構層面：缺乏職務分離
- 技術層面：無 API Gate 與審批
- 流程層面：無工單與核准

### Solution Design（解決方案設計）
解決策略：簽章器服務化並隔離；導入工單與雙人審批；權限細分（查看/申請/核准/簽章/發放）；全程稽核與告警。

實施步驟：
1. 角色與權限定義
- 實作細節：RBAC 模型
- 所需資源：身分系統
- 預估時間：0.5 週

2. 工單與審批
- 實作細節：發碼需核准才觸發簽章
- 所需資源：審批平台
- 預估時間：1 週

3. 稽核與告警
- 實作細節：全鏈路日誌、異常行為通知
- 所需資源：SIEM
- 預估時間：0.5 週

關鍵程式碼/設定：
```csharp
// 簽章 API 僅接受「已核准」工單編號
[Authorize(Roles = "Issuer")]
[HttpPost("sign")]
public IActionResult Sign(SignRequest req)
{
    if (!ApprovalService.IsApproved(req.TicketId)) return Forbid();
    var sig = Signer.Sign(req.Payload);
    Audit.Log("SIGN", User.Identity!.Name!, req.TicketId, req.PayloadId);
    return Ok(new { signature = Convert.ToBase64String(sig) });
}

## Case #14: 驗證事件稽核與異常偵測—快速發現濫用

### Problem Statement（問題陳述）
業務場景：需要快速偵測授權濫用（大量失敗驗證、序號重複、地理異常），以便阻斷與取證。
技術挑戰：定義事件、收集、告警與回應。
影響範圍：全體客戶端與後端維運。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 客戶端驗證結果未上報
2. 後端無彙整與基線
3. 缺少告警規則與自動化
深層原因：
- 架構層面：無遙測通道
- 技術層面：未做事件標準化
- 流程層面：無 SOC/值班流程

### Solution Design（解決方案設計）
解決策略：標準化授權事件（成功/失敗/封鎖），以結構化日誌上報匯流排，集中到 SIEM/監控，設告警阈值與自動封鎖策略。

實施步驟：
1. 事件定義與模型
- 實作細節：eventId, tenant, deviceId, reason
- 所需資源：Schema、SDK
- 預估時間：0.5 週

2. 收集與聚合
- 實作細節：批量/匿名化、隱私保護
- 所需資源：Log/Queue/SIEM
- 預估時間：1 週

3. 告警與回應
- 實作細節：規則、封鎖 API、工單
- 所需資源：監控平台
- 預估時間：0.5 週

關鍵程式碼/設定：
```csharp
// Serilog 上報結構化事件
Log.Information("license.verify {result} {device} {reason} {kid}",
    "fail", deviceId, "sig_invalid", kid);

## Case #15: 成本與風險折衷—混合策略（內嵌 + 回連 + 手動核發）

### Problem Statement（問題陳述）
業務場景：中小型軟體商預算有限，無法同時自建 PKI 與全硬體保護，但仍須達到足夠安全與可運營。
技術挑戰：選擇一組可演進、具成本效益的組合方案。
影響範圍：策略決策與里程碑規劃。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. CA 年費與維運成本
2. 硬體平台不可控
3. 用戶環境參差，網路限制多
深層原因：
- 架構層面：一刀切方案不可行
- 技術層面：缺乏漸進式安全設計
- 流程層面：無版本/群組策略

### Solution Design（解決方案設計）
解決策略：短期內嵌公鑰 + 簽章更新 + 基本回連（寬限 14 天）；高安客戶提供離線挑戰/回應；中長期導入 CA 與多鑰輪替，最終再評估 TPM 化。

實施步驟：
1. 安全最小集合
- 實作細節：Case #2、#6、#5（核心）
- 所需資源：有限
- 預估時間：2-4 週

2. 高安客戶方案
- 實作細節：Case #7（離線）
- 所需資源：工具與流程
- 預估時間：1-2 週

3. 中長期演進
- 實作細節：Case #3/#4/#9 演進路線
- 所需資源：投入評估
- 預估時間：季度計畫

關鍵程式碼/設定：
```csharp
// 以策略選擇驗證路徑（偽代碼）
LicenseResult Verify(License lic)
{
    if (!VerifyEmbeddedKey(lic)) return Fail("key_pinned_mismatch");
    if (!VerifyUpdateSignature()) return Fail("update_required");

    if (IsOnline())
    {
        var ok = TryRenew();
        if (!ok && DaysSinceLastRenew() > 14) return Fail("grace_expired");
    }
    else RecordOfflineUse();

    return Success();
}