架構分析不只是找出風險，而是從信任、暴露、資產與可用性四個面向，判斷企業應該如何配置有限的資源。

從風險與需求出發，判斷架構該如何設計

前一章從架構圖開始，說明架構師閱讀架構時，需要先理解系統如何運作、資料如何流動，以及不同元件之間如何建立關係。

但當架構師掌握這些資訊之後，下一個問題並不是「這裡有沒有漏洞」，而是：

這套架構是否能夠支撐企業長期的安全、治理與營運需求？

因為企業不可能對所有系統、所有元件以及所有資料，都投入相同程度的安全控制與基礎建設資源。真正的架構分析，需要進一步判斷哪些地方風險較高、哪些資產更加重要，以及哪些設計需要優先強化。

從我的實務經驗來看，我通常會從四個面向開始分析一套架構：信任邊界（Trust Boundary）、攻擊面（Attack Surface）、高價值資產（Critical Assets），以及單點故障（Single Point of Failure）。

這四個面向看的事情不同，但放在一起之後，可以幫助架構師逐步回答四個重要問題：

• 系統位於什麼位置，防禦應該如何配置？
• 系統可能從哪些角度暴露於攻擊之下？
• 有限的資源應該優先保護什麼？
• 哪些服務不能因為單一故障而中斷？

這些判斷最後都會回到架構決策本身，影響企業應該建立哪些控制、投入多少資源，以及哪些能力需要被優先納入設計。

信任邊界：決定防禦控制的範圍與程度

分析架構時，我通常會先確認系統在整體環境中的位置，以及它與其他環境、系統或服務之間的邊界。這不只是確認網路是否連通，而是要理解系統實際處於什麼位置、哪些流量可以進入，以及哪些資料或操作需要跨越不同的邊界。

例如，Internet 與企業內部網路之間、使用者與應用系統之間、正式環境與開發環境之間，以及企業系統與第三方服務之間，都可能形成不同的信任邊界。這些邊界的位置不同，所承受的風險也不同，因此需要配置的防禦控制也不會完全相同。

因此，閱讀架構圖時，我會進一步確認：這個系統的邊界究竟在哪裡？哪些地方需要建立防禦？控制應該配置在哪一個位置？又應該做到什麼程度？

這也是為什麼在架構設計中，不能只看到「有沒有防火牆」、「有沒有 WAF」或「有沒有 MFA」，而需要先理解這些控制應該放在哪個位置，以及它們各自要解決什麼問題。不同邊界所需要的控制可能不同，同一個控制也可能因為部署位置不同，而產生不同的防護效果。

從這個角度來看，信任邊界不是單純的網路區隔，而是協助架構師判斷防禦位置與控制程度的設計依據。當系統跨越不同環境、不同網路或不同管理範圍時，就需要重新檢視這個邊界是否已經被適當地保護，以及現有的控制是否足以支撐企業對安全的要求。

攻擊面：控制系統對外暴露風險

建立信任邊界之後，下一個需要確認的是：這套架構到底暴露了多少可以被攻擊的入口？

對外網站、公開 API、遠端管理介面、第三方整合服務，甚至某些看似正常的資料交換機制，都可能成為攻擊者接觸企業環境的入口。

但架構師並不是看到 Internet-facing 就要求全部關閉，因為企業本身就可能需要提供公開服務。真正需要分析的是，每一個暴露面是否都有合理的業務目的，以及是否已經建立與風險相對應的控制。

例如，一個對外提供服務的 API，可能需要經過身分驗證、授權、流量限制與 WAF 保護；管理介面則可能根本不應該直接暴露於 Internet，而應該透過 VPN、Privileged Access 或其他受控方式進行存取。

因此，攻擊面分析的目的不是追求「零攻擊面」，而是讓企業知道哪些入口是必要的、哪些入口可以移除，以及哪些入口需要投入更多防護資源。

當架構師把攻擊面與前面的信任邊界放在一起看，就能進一步判斷：哪些地方需要增加隔離、哪些地方需要增加控制，以及哪些暴露其實是可以透過架構調整直接降低的。

高價值資產：決定資源分配的優先順序

接下來，我會進一步確認一件事情：如果企業真的遭到攻擊或發生故障，哪一些資產受到影響會最嚴重？

因為企業的資源永遠有限，不可能所有系統都採用最高等級的安全控制，也不可能所有服務都建置相同程度的備援。

例如，公開網站、內部報表系統與核心身分平台，對企業的重要程度可能完全不同。某些系統即使暫時停止服務，影響可能有限；但如果核心身分服務、重要資料庫、金鑰管理系統或關鍵業務平台發生問題，影響可能快速擴散到其他系統。

因此，架構師需要先找出這些 高價值資產（Critical Assets），再思考它們需要什麼程度的保護。

這個判斷會直接影響企業資源如何配置。例如高價值資產可能需要更嚴格的存取控制、更高等級的監控、更完整的備份與復原機制，甚至需要跨區域的高可用性設計。

換句話說，識別高價值資產的目的，不只是「知道什麼重要」，而是把這個判斷轉換成資源優先順序。

當企業無法同時把所有系統做到最高等級時，架構師更需要協助企業找出有限的預算、人力與技術能力，究竟應該先投入在哪些地方？

單點故障：評估服務持續可用與架構韌性

除了安全風險之外，架構分析也必須考慮服務持續運作的需求。判斷一套架構是否需要建立高可用性（High Availability, HA），不能單純從「這個元件看起來重不重要」開始，而應該先確認企業對這項服務所要求的 SLA（Service Level Agreement）。

例如，一項服務如果要求全年維持高度可用，就代表架構必須具備相對應的容錯與備援能力；如果服務允許較長的中斷時間，則可以採用不同程度的可用性設計。換句話說，SLA 所要求的服務可用程度，會直接影響架構需要建立多少備援能力。

因此，在閱讀架構圖時，我通常會先確認這套系統的 SLA 與業務需求，再沿著服務的相依關係往下分析：如果其中某一個元件發生故障，是否會讓整體服務無法達到既定的 SLA？如果會，就需要進一步評估該元件是否需要備援、容錯或其他高可用性設計。

例如單一資料庫、單一網路設備、單一區域、單一身分服務，甚至某一個沒有備援的第三方服務，都可能形成 Single Point of Failure（SPOF）。真正需要關注的不是這些元件本身是不是「重要」，而是它們是否成為影響服務 SLA 的關鍵依賴。

但高可用性也不是「所有東西都做雙份」。建立備援需要額外的基礎建設、維運能力與成本，因此仍然需要回到前面高價值資產的判斷。

越重要的服務，越值得投入更高程度的可用性設計；反過來，如果某項服務中斷的業務影響很低，就不一定需要採用最高等級的 HA 架構。

因此，高可用性不是單純的技術選擇，而是企業根據 SLA、業務重要性與風險所做出的資源配置決策。

四個面向最後會回到同一個架構決策

從信任邊界、攻擊面、高價值資產到單點故障，看起來是在分析四種不同的問題，但實際上它們最後都會交會到同一個地方：企業應該如何配置有限的資源，讓整體架構維持在可以接受的風險範圍內。

信任邊界讓架構師思考如何建立隔離與縱深防禦；攻擊面讓架構師確認哪些暴露需要降低或加強控制；高價值資產讓企業知道哪些地方應該優先投入資源；單點故障則協助判斷哪些服務需要更高程度的可用性與韌性。

因此，架構師看到一張架構圖時，並不是單純找「哪裡不安全」，而是在理解整體設計之後，逐步判斷哪些地方值得優先處理、哪些控制值得投入，以及哪些風險可以接受。

這也是架構分析與單純技術檢查最大的差異。

小結

架構分析的價值，不只是找出架構中的問題，而是協助企業理解風險應該如何被管理，以及資源應該如何被配置。

透過信任邊界，可以建立不同層次的隔離與縱深防禦；透過攻擊面，可以掌握企業對外暴露的風險；透過高價值資產，可以決定有限資源應該優先保護哪些對象；透過單點故障，則可以判斷哪些服務需要投入更高程度的可用性與復原能力。

這四個面向並不是四個獨立的檢查清單，而是架構師分析系統時的一套思考脈絡。從系統如何建立信任開始，逐步理解它暴露在哪裡、什麼最值得保護，以及哪些地方不能輕易失效，最後再將這些判斷轉換成具體的架構設計與資源配置。

這也是架構師在企業治理中重要的價值：不是讓所有系統都做到最高標準，而是協助企業在有限資源下，把最重要的控制放在最需要的地方。