使用安全Web裝置最佳做法
簡介
本文檔介紹如何配置思科安全網路裝置(SWA)的最佳實踐。
背景資訊
本指南旨在作為最佳做法配置的參考，它涉及SWA部署的多個方面，包括支援的網路環境、策略配置、監控和故障排除。雖然此處記錄的最佳實踐對於所有管理員、架構師和操作員都很重要，但是它們只是指導原則，並且必須這樣對待。每個網路都有其自身的具體要求和挑戰。
作為安全裝置，SWA以幾種獨特的方式與網路互動。它既是Web流量的來源也是目的地；同時充當Web伺服器和Web客戶端。它至少使用伺服器端IP地址欺騙和中間人技術來檢查HTTPS事務。它還可以偽裝客戶端IP地址，這會增加部署的另一層複雜性，並對支援網路配置提出額外要求。本指南解決與相關的網路裝置配置相關的最常見問題。
SWA策略配置不僅影響安全效能和實施，而且影響裝置的效能。本指南介紹配置的複雜性如何影響系統資源。它定義了此環境中的複雜性，並描述了如何在策略設計中將其最小化。另外還關注特定功能，以及如何配置這些功能，以提高安全性、可擴充性和有效性。
本文檔的監控和警報部分介紹了監控裝置的最有效方法；還介紹了對效能和可用性以及系統資源使用情況的監控。它還提供了對基本故障排除有用的資訊。
網路環境
ICMP
路徑MTU探索(如RFC 1191所定義)。此機制可確定沿任意路徑的資料包的最大大小。若是IPv4，則裝置可通過在封包的IP標頭中設定不分段(DF)位元，來確定路徑上任何封包的最大傳輸單位(MTU)。如果路徑沿途的某條連結上的裝置無法轉送封包而不將其分段，則會將需要Internet控制訊息通訊協定(ICMP)分段（型別3，代碼4）訊息傳送回來源。然後使用者端重新傳送較小的封包。此過程會一直持續，直到找到完整路徑的MTU。IPv6不支援分段，並且使用「資料包過大（型別2）」ICMPv6消息表示無法通過給定鏈路容納資料包。
由於封包分段程式可能會對TCP資料流的效能產生嚴重影響，因此SWA會利用路徑MTU探索。必須在相關網路裝置中啟用提到的ICMP消息，以允許SWA確定其通過網路路徑的MTU。在使用pathmtudiscovery命令列介面(command-line interface， CLI)命令的SWA中可以禁用此行為。執行此操作會導致預設MTU下降至576位元組（根據RFC 879），嚴重影響了效能。管理員還必須執行其他步驟，從中手動配置SWA中的MTU etherconfig CLI指令。
在網路快取通訊協定(WCCP)的情況下，網路流量會從另一個網路裝置沿著使用者端路徑重新導向到SWA，到達網際網路。在這種情況下，其他通訊協定（例如ICMP）不會重新導向到SWA。SWA可能會觸發來自網路上路由器的ICMP需要分段消息，但不會將該消息傳送到SWA。如果網路中有可能出現這種情況，必須禁用路徑MTU發現。如前所述，通過此配置，在SWA上手動設定MTU的附加步驟 etherconfig 需要CLI命令。
防火牆
在預設配置中，代理連線時，SWA不會欺騙客戶端IP地址。這意味著所有出站Web流量均源自SWA IP地址。必須確保網路位址轉譯(NAT)裝置具有足夠大的外部位址和連線埠池來容納此內容。為此指定特定地址是一個好主意。
有些防火牆採用拒絕服務(DoS)保護或其他安全功能，當大量同時連線源自單個客戶端IP地址時觸發這些功能。如果未啟用客戶端IP欺騙，則必須將SWA IP地址排除在這些保護之外。
單點傳送反向路徑轉送
SWA在與客戶端通訊時偽裝伺服器IP地址，並且可選地可配置為在與上游伺服器通訊時偽裝客戶端IP地址。可在交換器上啟用單點傳送反向路徑轉送(uRPF)等保護，以確保傳入封包與預期輸入連線埠相符。這些保護根據路由表檢查資料包的源介面，以確保它到達預期的埠。SWA需要酌情豁免這些保護。
使用WCCP進行IP欺騙
當SWA中啟用IP欺騙功能時，出站請求會使裝置使用原始客戶端請求的源地址。這需要對相關網路基礎設施進行額外配置，以確保返回的資料包被路由到SWA出站介面，而不是發出請求的客戶端。
在網路裝置（路由器、交換機或防火牆）上實施WCCP時，會定義一個服務ID，該服務ID根據訪問控制清單(ACL)匹配流量。然後服務ID應用於介面，並用於匹配流量以進行重定向。如果啟用IP欺騙，則必須建立第二個服務ID，以確保返回的流量也重定向到SWA。
SWA網路配置
介面
SWA有五個可用的網路介面：M1、P1、P2、T1和T2。在可能的情況下，必須針對其特定目的來利用上述每個功能。由於自身的原因使用每個埠是有益的。M1介面必須連線到專用管理網路，並且必須啟用分割路由以限制管理服務的洩露。P1可以限製為客戶端請求流量，相反，不允許P2接受顯式代理請求。這樣可以減少每個介面上的流量並在網路設計中實現更好的分段。
T1和T2連線埠可用於第4層流量監控器(L4TM)功能。此功能可監控映象的第2層埠，並增加了根據已阻止的已知惡意IP地址和域名清單阻止流量的功能。它通過檢視流量的來源和目的地IP位址來完成此操作，並傳送TCP重設封包，或如果封鎖清單相符，傳送Port Unreachable訊息。使用此功能可以阻止使用任何協定傳送的流量。
即使L4TM功能未啟用，當T1和T2連線埠連線到映象連線埠時，透通旁路功能也會增強。對於WCCP，SWA只知道傳入資料包的源和目標IP地址，必須決定代理或基於該資訊繞過它。SWA每30分鐘解析一次旁路設定清單中的任何條目，而不管記錄的生存時間(TTL)。但是，如果已啟用L4TM功能，則SWA可以使用已監聽的DNS查詢更頻繁地更新這些記錄。這降低了客戶端解析了與SWA不同的地址的情況下出現誤報的風險。
管理網路路由
如果專用管理網路不能訪問Internet，則可以將每項服務配置為使用資料路由表。這可以定製為適合網路拓撲，但通常建議對所有系統服務使用管理網路，對客戶端流量使用資料網路。自AsyncOS版本11.0起，可以設定路由的服務包括：
- 外部URL源
- 進階惡意軟體防護(AMP)檔案信譽和分析
- 更新和升級
- DNS
- Active directory
對於管理流量的其他出口過濾，可以配置靜態地址以用於以下服務：
- 外部URL源：
1.自定義取決於託管位置
2.AMP檔案信譽和分析
3. cloud-sa.amp.cisco.com（北美）
4. cloud-sa.eu.amp.cisco.com（歐洲）
5.cloud-sa.apjc.amp.cisco.com（亞太地區）
- 更新和升級：
1. downloads-static.ironport.com
2. updates-static.ironport.com
TALOS遙測
Cisco Talos組以識別新出現威脅而聞名。所有傳送到Talos的資料都是匿名的，並儲存在美國資料中心。參與SensorBase可以增強對Web威脅的分類和識別，從而更好地保護SWA以及其他思科安全解決方案。
DNS
域名伺服器(DNS)安全最佳實踐建議每個網路必須託管兩個DNS解析器：一個用於本地域內的授權記錄，另一個用於網際網路域的遞迴解析。為了適應此情況，SWA允許為特定域配置DNS伺服器。如果只有一個DNS伺服器可用於本地查詢和遞迴查詢，請考慮在用於所有SWA查詢時它增加的額外負載。更好的選項可以是使用本地域的內部解析器和外部域的根Internet解析器。這取決於管理員的風險設定和容差。
預設情況下，無論記錄的TTL如何，SWA都會快取DNS記錄至少30分鐘。大量使用內容交付網絡(CDN)的現代網站的TTL記錄較低，因為其IP地址經常更改。這可能會導致客戶端快取給定伺服器的IP地址，並且SWA快取同一伺服器的不同地址。為了解決此問題，SWA預設TTL可以從以下CLI命令降低到五分鐘：
SWA_CLI> dnsconfig
...
Choose the operation you want to perform:
- NEW - Add a new server.
- EDIT - Edit a server.
- DELETE - Remove a server.
- SETUP - Configure general settings.
- SEARCH - Configure DNS domain search list.
[]> SETUP
...
Enter the minimum TTL in seconds for DNS cache.
...
輔助DNS伺服器必須配置，以防主伺服器不可用。如果所有伺服器都配置了相同的優先順序，則會隨機選擇伺服器IP。根據配置的伺服器數量，給定伺服器的超時值會有所不同。該表是最多六台DNS伺服器的查詢超時：
| DNS伺服器數量 | 查詢超時（按順序） |
| 1 | 60 |
| 2 | 5、45 |
| 3 | 5、10、45 |
| 4 | 1、3、11、45 |
| 5 | 1、3、11、45、1 |
| 6 | 1、3、11、45、1、1 |
也有一些高級DNS選項只能通過CLI使用。CLI中提供了以下選項：
advancedproxyconfig > DNS 指令。選擇以下選項之一：
- 0 — 始終按順序使用DNS應答
- 1 — 使用客戶端提供的地址，然後使用DNS
- 2 — 有限的DNS使用
- 3 -DNS使用非常有限
對於選項1和2，如果啟用Web信譽，則使用DNS。
對於選項2和3，如果沒有上游代理，或在配置的上游代理發生故障的情況下，DNS用於顯式代理請求。
對於所有選項，在策略成員身份中使用目標IP地址時使用DNS。
這些選項控制SWA在評估客戶端請求時如何決定要連線的IP地址。收到請求後，SWA會看到目標IP地址和主機名。SWA必須決定是否信任TCP連線的原始目標IP地址，還是執行自己的DNS解析並使用已解析的地址。預設值為「0 =始終按順序使用DNS答案」，這表示SWA不信任客戶端提供IP地址。
- 選項1 - SWA嘗試連線由客戶端提供的IP地址，但如果失敗，則回退到解析地址。解析的地址用於策略評估(Web類別、Web信譽等)。
- 選項2 - SWA僅使用客戶端提供的地址進行連線，不會回退。解析的地址用於策略評估（Web類別、Web信譽等）。
- 選項3 - SWA僅使用客戶端提供的地址進行連線，不會回退。客戶端提供的IP地址用於策略評估（Web類別、Web信譽等）。
所選擇的選項取決於管理員在確定給定主機名的解析地址時必須給予客戶端的信任程度。如果使用者端是下游代理，請選擇選項3以避免不必要的DNS查詢增加延遲。
負載平衡
當使用最多八台裝置時，WCCP允許透明流量負載均衡。它允許根據雜湊或掩碼平衡流量，如果網路中混合了裝置模型，則可以對流量進行加權，並且可以在不中斷服務的情況下新增裝置並將其從服務池中刪除。一旦需求超過了可使用八個SWA處理的需求，建議使用專用負載均衡器。
WCCP配置的具體最佳實踐因使用的平台而異。對於Cisco Catalyst®交換機，最佳實踐記錄在Cisco Catalyst Instant Access Solution白皮書中。
WCCP在與Cisco Adaptive Security Appliance(ASA)配合使用時存在限制。即不支援客戶端IP欺騙，客戶端和SWA必須位於同一介面之後。因此，使用第4層交換器或路由器來重新導向流量會更靈活。ASA平台上的WCCP配置在ASA上的WCCP：概念、限制和配置中說明。
對於顯式部署，代理自動配置(PAC)檔案是部署最廣泛的方法，但它有許多缺點和安全影響超出了本文檔的範圍。如果部署了PAC檔案，建議使用組策略對象(GPO)配置位置，而不是依賴Web代理自動發現協定(WPAD),WPAD是攻擊者的常見目標，如果配置錯誤，很容易被利用。SWA可以託管多個PAC檔案並在瀏覽器的快取中控制其過期。
可以通過可配置的TCP埠號（預設情況下為9001）直接從SWA請求PAC檔案。如果沒有指定埠，請求可以像出站Web請求一樣傳送到代理進程本身。在這種情況下，可以根據請求中存在的HTTP主機標頭為特定PAC檔案提供服務。
在高可用性環境中使用時，Kerberos的配置必須不同。SWA支援keytab檔案，從而允許多個主機名與服務原則名稱(SPN)關聯。有關詳細資訊，請參閱在Windows Active Directory中建立服務帳戶，以在高可用性部署中進行Kerberos身份驗證。
主動驗證
與NT LAN管理器安全支援提供程式(NTLMSSP)相比,Kerberos更安全，並且廣泛支援身份驗證協定。Apple OS X作業系統不支援NTLMSSP，但是如果域已加入，則可以使用Kerberos進行身份驗證。不能使用基本身份驗證，因為它在HTTP報頭中傳送未加密的憑據，並且很容易被網路上的攻擊者嗅探。如果必須使用基本身份驗證，則必須啟用憑據加密以確保通過加密隧道傳送憑據。
必須將多個域控制器新增到配置以確保可用性，但是此流量沒有固有的負載平衡。SWA將TCP SYN資料包傳送到所有已配置的域控制器，第一個響應資料包用於身份驗證。
在authentication settings頁面中配置的「redirect hostname」（重定向主機名）可確定透明客戶端的傳送位置，以便完成身份驗證。要使Windows客戶端完成整合身份驗證並實現單點登入(Single Sign-On， SSO)，重定向主機名必須位於「Internet選項」控制面板中的「受信任的站點」區域。Kerberos協定要求使用完全限定域名(FQDN)指定資源，這意味著，如果Kerberos是預期的身份驗證機制，則不能使用「短名稱」（或「NETBIOS」名稱）。需要將FQDN手動新增到「受信任的站點」（例如，通過組策略）。此外，還必須在「Internet選項」控制面板中設定「使用使用者名稱和密碼自動登入」。
瀏覽器還需要在Firefox中進行其他設定，才能完成網路代理的身份驗證。可以在about:config頁中配置這些設定。要成功完成Kerberos，必須將重定向主機名新增到network.negotiate-auth.trusted-uris選項。對於NTLMSSP，必須將其新增到network.automatic-ntlm-auth.trusted-uris選項。
身份驗證完成後，身份驗證代理用於記住經過身份驗證的使用者的設定持續時間。必須儘可能使用IP代理來限制發生的主動身份驗證事件的數量。主動驗證客戶端是一項資源密集型任務，在使用Kerberos時尤其如此。代理超時預設情況下為3600秒（1小時），可以減少，但建議的最低值為900秒（15分鐘）。
此圖顯示「redirect.WSA.lab」如何用作重定向主機名。
被動驗證
SWA可以利用其他思科安全平台被動地識別代理使用者。被動使用者識別無需直接身份驗證質詢以及來自SWA的任何Active Directory通訊，這反過來降低了裝置上的延遲和資源使用率。當前可用的被動身份驗證機制是通過情景目錄代理(CDA)、身份服務引擎(ISE)和身份服務聯結器被動身份聯結器(ISE-PIC)。
ISE是一種功能豐富的產品，可幫助管理員集中其身份驗證服務，並利用廣泛的網路訪問控制。當ISE獲知使用者身份驗證事件（通過Dot1x身份驗證或Web身份驗證重定向）時，它會填充包含有關身份驗證中涉及的使用者和裝置的資訊的會話資料庫。SWA通過Platform Exchange Grid(pxGrid)連線到ISE，並獲取與代理連線關聯的使用者名稱、IP地址和安全組標籤(SGT)。自AsyncOS版本11.7起，SWA還可以查詢ISE上的外部Restful服務(ERS)以獲取組資訊。
建議版本為ISE 3.1和SWA 14.0.2-X及更高版本。有關SWA的ISE相容性矩陣的詳細資訊，請參閱安全Web裝置的ISE相容性矩陣。
有關完全整合步驟的詳細資訊，請參閱網路安全裝置最終使用手冊。
思科宣佈Cisco Context Directory Agent(CDA)軟體的生命週期終止，請參閱Cisco Context Directory Agent(CDA)。
自CDA補丁6起，與Microsoft Server 2016相容。但是，我們積極鼓勵管理員將其CDA部署遷移到ISE-PIC。兩種解決方案都使用WMI來訂閱Windows安全事件日誌以生成使用者到IP的對映（稱為「會話」）。對於CDA，SWA使用RADIUS查詢這些對映。對於ISE-PIC，使用與完整ISE部署相同的pxGrid和ERS連線。ISE-PIC功能可在完整ISE安裝以及獨立虛擬裝置中使用。
服務配置
Web代理
必須在Web代理配置中啟用快取，才能節省頻寬並提高效能。隨著HTTPS流量百分比的提高，這一點變得不那麼重要，因為SWA不會預設快取HTTPS事務。如果部署代理僅服務於顯式客戶端，則必須指定轉發模式，以便拒絕任何未明確定向到代理服務的流量。通過這種方式，裝置攻擊面得以減少，並且實施了一個良好的安全原則：如果不需要則將其關閉。
HTTP請求中使用範圍請求標頭來指定要下載的檔案的位元組範圍。它通常由作業系統和應用程式更新守護程式用於一次傳輸檔案的小部分。預設情況下，SWA剝離這些報頭，以便獲取整個檔案，用於防病毒(AV)掃描、檔案信譽和分析以及應用可視性控制(AVC)。通過在代理設定中全域性啟用範圍請求報頭的轉發，管理員可以建立轉發或剝離這些報頭的單獨訪問策略。有關此配置的更多資訊，請參閱訪問策略一節。
HTTPS代理
安全最佳實踐建議，必須在使用私鑰的裝置上生成私鑰，並且不得將私鑰傳送到其他位置。HTTPS代理嚮導允許建立金鑰對和用於傳輸層安全(TLS)連接解密的證書。然後,憑證簽署請求(CSR)可下載並由內部憑證授權單位(CA)簽署。在Active Directory(AD)環境中，這是最佳方法，因為AD整合的CA自動受域所有成員的信任，並且不需要其他步驟來部署證書。
HTTPS代理的一個安全功能是驗證伺服器證書。最佳實踐建議無效證書要求斷開連線。啟用Decrypt for EUN允許SWA顯示塊頁，解釋塊的原因。如果未啟用此功能，則任何被阻止的HTTPS站點都會導致瀏覽器錯誤。這會增加幫助台票證，並且使用者認為某些東西已損壞，而不是知道SWA已阻止連線。所有無效的證書選項都必須至少設定為Decrypt。如果將其中任何選項保留為監視器，則在證書問題阻止載入站點時，無法記錄有用的錯誤消息。
同樣，必須啟用Online Certificate Services Protocol(OCSP)檢查，並且不能將監視器用於任何選項。必須丟棄吊銷的證書，並且所有其他證書必須至少設定為「解密」，以允許記錄相關錯誤消息。授權資訊訪問追蹤（AIA追蹤）是一種客戶端可以收集證書簽名者以及獲取附加證書的URL的方法。例如，如果從伺服器接收的證書鏈不完整（它缺少中間或根證書），則SWA可以檢查AIA欄位並使用該欄位獲取缺少的證書並驗證真實性。此設定僅在CLI中從以下命令可用：
SWA_CLI> advancedproxyconfig
Choose a parameter group:
- AUTHENTICATION - Authentication related parameters
- CACHING - Proxy Caching related parameters
- DNS - DNS related parameters
- EUN - EUN related parameters
- NATIVEFTP - Native FTP related parameters
- FTPOVERHTTP - FTP Over HTTP related parameters
- HTTPS - HTTPS related parameters
- SCANNING - Scanning related parameters
- PROXYCONN - Proxy connection header related parameters
- CUSTOMHEADERS - Manage custom request headers for specific domains
- MISCELLANEOUS - Miscellaneous proxy related parameters
- SOCKS - SOCKS Proxy parameters
- CONTENT-ENCODING - Block content-encoding types
- SCANNERS - Scanner related parameters
[]> HTTPS
...
Do you want to enable automatic discovery and download of missing Intermediate Certificates?
[Y]>
...
第4層流量監控器(L4TM)
L4TM是將SWA的覆蓋範圍擴展到包括不通過代理的惡意流量（包括所有TCP和UDP埠上的流量）的高效方法。T1和T2埠應連線到網路分路器或交換機監控會話，從而允許SWA被動地監控來自客戶端的所有流量。如果發現發往惡意IP地址的流量，SWA可以在欺騙伺服器IP地址的同時通過傳送RST來終止TCP會話。若是UDP流量，它可傳送連線埠無法連線訊息。配置監控會話時，最好排除任何目的地為SWA管理介面的流量，以避免該功能可能干擾對裝置的訪問。
除了監控惡意流量外，L4TM還會監聽DNS查詢，以更新繞過設定清單。此清單用於WCCP部署，用於將某些請求返回到WCCP路由器，以便直接路由到Web伺服器。代理不會處理與旁路設定清單匹配的資料包。清單可以包含IP地址或伺服器名稱。SWA每30分鐘解析一次旁路設定清單中的任何條目，無論記錄的TTL如何。但是，如果已啟用L4TM功能，則SWA可以使用已監聽的DNS查詢更頻繁地更新這些記錄。這降低了客戶端解析了與SWA不同的地址的情況下出現誤報的風險。
策略配置
正確的策略配置對於SWA的效能和可擴充性至關重要。之所以如此，不僅是因為政策本身對保護客戶和執行公司要求的有效性。策略配置方式會直接影響資源使用情況以及SWA的整體運行狀況和效能。過於複雜或設計欠佳的策略集可能導致裝置的不穩定和響應速度緩慢。
複雜性
在制訂全部門辦法政策時採用了各種政策要素。從配置生成的XML檔案用於建立大量後端配置檔案和訪問規則。配置越複雜，代理進程需要花費更多時間來評估每個事務的各種規則集。在設定基準和調整SWA規模時，會建立一組基本策略要素，這些要素代表配置複雜性的三個層次。10個身份配置檔案、解密策略和訪問策略，以及10個包含10個正規表示式條目、50個伺服器IP地址和420個伺服器主機名的自定義類別，被視為低複雜性配置。將每個數字乘以2和3分別得到中等複雜性和高複雜性的配置。
當配置變得過於複雜時，最初的症狀通常包括Web介面和CLI響應緩慢。一開始不會對使用者造成重大影響。但是，配置越複雜，代理進程在使用者模式下必須花費的時間就越長。因此，檢查此模式花費的時間百分比是一種有用的方法，可將過於複雜的配置診斷為SWA緩慢的原因。
CPU時間（以秒為單位）每五分鐘記錄在track_stats日誌中。這意味著使用者時間百分比可以計算為（使用者時間+系統時間）/300。當使用者時間接近270時，該進程在使用者模式下花費過多的CPU週期，這幾乎總是因為配置太複雜而無法有效地分析。
注意：到目前為止，SWA的最大限制是60,000個併發客戶端連線和60,000個併發伺服器連線。
標識配置檔案
標識(ID)配置檔案是在接收新請求時評估的第一策略元素。ID配置檔案第一部分配置的所有資訊都將使用邏輯AND進行評估。這意味著所有條件必須匹配，請求才能與配置檔案匹配。建立策略時，策略必須具體到絕對必要的程度。包含單個主機地址的配置檔案幾乎從不需要使用，而且可能會導致配置蔓延。利用HTTP標頭、自定義類別清單或子網中的使用者代理字串通常是限制配置檔案範圍的更好策略。
通常，需要身份驗證的策略在底部配置，並在頂部新增異常。在對不需要身份驗證的策略進行排序時，最常用的策略必須儘可能最接近頂部。不要依賴失敗的身份驗證來限制訪問。如果已知網路上的客戶端無法對Proxy進行身份驗證，則必須在訪問策略中免除身份驗證並阻止該客戶端。無法進行身份驗證的客戶端會反複向SWA傳送未經身份驗證的請求，這會佔用資源並導致CPU和記憶體使用過度。
管理員的一個常見誤解是必須有一個唯一的ID配置檔案以及相應的解密策略和訪問策略。對於策略配置而言，這種策略效率很低。如有可能，策略必須被「摺疊」，以便單個ID配置檔案可以與多個解密和訪問策略相關聯。這是可能的，因為給定的策略中的所有條件必須匹配，流量才能與策略匹配。在身份驗證策略中更普通，在生成的策略中更具體，這樣可以減少整個策略的數量。
解密策略
與ID配置檔案一樣，解密策略中設定的條件也作為邏輯AND進行評估，但使用ISE中的資訊時有一個重要例外。以下是策略匹配的工作方式，取決於配置哪些元素（AD組、使用者或SGT）：
- AD組和使用者 — 對以前的行為無更改；如果使用者是組的成員，或者是在策略中指定使用者，則匹配策略。
- SGT和AD組和使用者 — 如果使用者與SGT關聯並且是AD組的成員，或者使用者在策略中指定，則匹配策略。
- SGT和使用者 — 如果使用者與SGT關聯或在策略中指定使用者，則匹配策略。
在SWA執行的所有服務中，從效能角度而言，對HTTPS流量的評估最為重要。已解密流量的百分比對裝置的大小有直接影響。管理員可以指望至少75%的網路流量是HTTPS。
初始安裝後，必須確定解密流量的百分比，以確保正確設定對未來增長的預期。部署後，必須每季度檢查一次此編號。使用access_logs的副本可以輕鬆查詢由SWA解密的HTTPS流量百分比，即使沒有額外的日誌管理軟體也是如此。可以使用簡單的Bash或PowerShell命令來獲取此數字。以下是針對每個環境介紹的步驟：
1.查詢HTTPS連線總數（顯式和透明）：
Bash:
grep -cE 'tunnel://|TCP_CONNECT' aclog.current
PowerShell:
(Get-Content aclog.current | Select-String -Pattern 'tunnel://|TCP_CONNECT').length2.查詢已解密HTTPS連線數：
Bash:
grep -E 'tunnel://|TCP_CONNECT' aclog.current | grep -c DECRYPT
PowerShell:
(Get-Content aclog.current | Select-String -Pattern 'tunnel://|TCP_CONNECT’| Select-String -Pattern ‘DECRYPT’).length3.將第二個值除以第一個值，再乘以100。
設計解密策略時，必須瞭解策略中列出的各種操作如何導致裝置評估HTTPS連線。當必須允許客戶端和伺服器終止其TLS會話的每一端而沒有SWA解密每個資料包時，會使用直通操作。即使站點設定為通過，也必須要求SWA與伺服器完成一次TLS握手。這是因為SWA必須選擇根據證書有效性阻止連線，並且必須啟動與伺服器的TLS連線以獲取證書。如果證書有效，SWA將關閉連線，並允許客戶端繼續直接與伺服器建立會話。
SWA不執行任何TLS握手的唯一情況是：伺服器名稱或IP地址存在於自定義類別中（設定為passthrough），並且伺服器名稱在HTTP CONNECT或TLS客戶端Hello中可用。在顯式方案中，客戶端在TLS會話發起之前將伺服器的主機名提供給Proxy（在主機標頭中），因此會根據自定義類別檢查此欄位。在透明部署中，SWA檢查TLS客戶端Hello消息中的伺服器名稱指示(SNI)欄位，並根據自定義類別評估該欄位。如果主機標頭或SNI不存在，SWA必須繼續與伺服器握手，以便按此順序檢查證書上的Subject Alternative Name(SAN)和Common Name(CN)欄位。
此行為對於策略設計意味著通過確定已知和內部受信任的伺服器並將其設定為從自定義類別清單傳遞，而不是依賴Web類別和信譽得分（這仍需要SWA與伺服器完成TLS握手），可以減少TLS握手的數量。但是，必須注意的是，這也會阻止證書有效性檢查。
新站點在Web上出現的速度，很可能是SWA使用的Web信譽和分類資料庫未分類的許多站點。這並不意味著該站點更可能是惡意站點，此外，所有這些站點仍會受到AV掃描、AMP檔案信譽和分析，以及配置的任何對象阻止或掃描。出於這些原因，建議不要在多數情況下丟棄未分類站點。最好將它們設定為由AV引擎解密和掃描，並由AVC、AMP、訪問策略等進行評估。有關未分類站點的詳細資訊，請參閱訪問策略部分。
訪問策略
與ID配置檔案一樣，解密策略中設定的條件也作為邏輯AND進行評估，當使用ISE中的資訊時，有一個重要例外。策略匹配行為根據配置的元素（AD組、使用者或SGT）進行說明：
- AD組和使用者 — 不更改以前的行為；如果使用者是組的成員，則策略匹配；或者在策略中指定使用者。
- SGT和AD組和使用者 — 如果使用者與SGT關聯且是AD組的成員，或者使用者在策略中指定，則策略匹配。
- SGT和使用者 — 如果使用者與SGT相關聯，則匹配策略；或者在策略中指定使用者。
HTTP流量在經過身份驗證後立即根據訪問策略進行評估。HTTPS流量在經過身份驗證後進行評估，並且如果根據匹配的解密策略應用了解密操作。對於已解密的請求，存在兩個access_log條目。第一個日誌條目顯示應用於初始TLS連線（解密）的操作，第二個日誌條目顯示由訪問策略應用於解密HTTP請求的操作。
如Web Proxy部分中所述，請求報頭用於請求檔案的特定位元組範圍，通常由作業系統和應用程式更新服務使用。預設情況下，SWA從出站請求中刪除這些報頭，因為如果沒有整個檔案，就無法執行惡意軟體掃描或利用AVC功能。如果網路中的許多主機頻繁請求小位元組範圍來檢索更新，則可能會觸發SWA同時下載整個檔案數次。這會快速耗儘可用的Internet頻寬並導致服務中斷。導致此故障情況的最常見原因是Microsoft Windows更新和Adobe軟體更新守護程式。
要緩解此問題，最佳解決方案是完全控制SWA周圍的流量。這對於透明部署的環境並非總是可行的，在這些情況下，下一個最佳選項是為流量建立專用訪問策略，並在這些策略上啟用範圍請求報頭轉發。必須考慮到AV掃描和AVC對於這些請求是不可能的，因此必須仔細設計策略以僅針對目標流量。通常，實現此目標的最佳方式是匹配請求報頭中的使用者代理字串。可以線上找到常見更新守護程式的使用者代理字串，或者由管理員捕獲並檢查請求。大多數更新服務（包括Microsoft Windows更新和Adobe軟體更新）未使用HTTPS。
如解密策略部分所述，不建議刪除解密策略中的未分類站點。出於同樣的原因，建議不要在訪問策略中阻止它們。動態內容分析(Dynamic Content Analysis， DCA)引擎可以使用給定網站的內容，以及其他啟發式資料來分類網站，否則這些網站將被URL資料庫查詢標籤為未分類。啟用此功能可減少SWA中未分類裁決的數量。
在訪問策略的「對象掃描」設定中，可以檢查多種型別的歸檔檔案。如果網路在應用程式更新過程中定期下載存檔檔案，啟用此功能會顯著增加CPU使用率。如果要檢查所有存檔檔案，必須提前識別並免除此流量。首先調查識別此流量的可能方法的是使用者代理字串，因為這樣有助於避免可能變得難以維護的IP允許清單。
自定義和外部URL類別
Custom category清單用於按IP地址或主機名標識伺服器。可以使用正規表示式(regex)指定伺服器名稱匹配的模式。與使用子字串匹配相比，使用regex模式匹配伺服器名稱要耗費大量資源，因此只有在絕對必要時才必須使用這些模式。可以在域名的開頭新增「。」以匹配子域，而無需正規表示式。例如，「.cisco.com」也與「www.cisco.com」匹配。
如複雜性一節所述，低複雜性定義為10個自定義類別清單，中等複雜性定義為20個，高複雜性定義為30個。建議將此數字保持在20以下，尤其是當清單使用regex模式或包含大量條目時。請參閱訪問策略部分，以瞭解有關每種型別的條目數量的其他詳細資訊。
外部URL源比靜態自定義類別清單靈活得多，利用這些源可能會對安全性產生直接影響，因為它們不再需要管理員手動維護這些源。由於此功能可用於檢索不由SWA管理員維護或控制的清單，因此在AsyncOS版本11.8中增加了將個別例外新增到下載地址的功能。
Office365 API對於針對此常見部署的服務做出策略決策特別有用，可用於單個應用程式（PowerPoint、Skype、Word等）。Microsoft建議繞過所有Office365流量的代理以最佳化效能。Microsoft文檔說明：
「雖然SSL Break和Inspect產生的延遲最大，但代理身份驗證和信譽查詢等其他服務可能導致效能降低和使用者體驗不良。此外，這些外圍網路裝置需要足夠的容量來處理所有網路連線請求。我們建議繞過代理或檢查裝置來獲得直接Office 365網路請求。」https://learn.microsoft.com/en-us/microsoft-365/enterprise/managing-office-365-endpoints?view=o365-worldwide。
在透明的代理環境中使用此指南可能很困難。從AsyncOS版本11.8開始，可以使用從Office365 API檢索的動態類別清單來填充旁路設定清單。此清單用於以透明方式將重新導向的流量傳送回WCCP裝置以進行直接路由。
繞過所有Office365流量會為需要一些基本安全控制和報告此流量的管理員建立盲點。如果SWA沒有繞過Office365流量，瞭解可能產生的具體技術挑戰就非常重要。其中之一是應用程式所需的連線數。必須適當調整大小，以適應Office365應用程式所需的其他持續TCP連線。這會將每個使用者的總連線數增加10到15個持續TCP會話。
HTTPS代理執行的解密和重新加密操作會為連線帶來少量延遲。Office365應用程式對延遲非常敏感，如果廣域網連線速度慢和地理位置分散等其他因素加劇了這一情況，使用者體驗可能會受到影響。
某些Office365應用程式使用專有的TLS引數，這些引數會阻止HTTPS代理與應用程式伺服器完成握手。驗證證書或檢索主機名時需要執行此操作。如果將此應用程式與Skype for Business等應用程式結合使用，而該應用程式不會在其TLS客戶端Hello消息中傳送伺服器名稱指示(Server Name Indication， SNI)字段，則有必要完全繞過此流量。AsyncOS 11.8引入了隻根據目標IP地址繞過流量，而不進行證書檢查來解決此情況的功能。
監控器和警報
CLI監控器
SWA CLI提供即時監控重要進程的命令。最有用的命令是顯示與代理進程相關的統計資訊的命令。status detail命令是資源使用量和效能度量摘要的良好來源，包括正常運行時間、使用的頻寬、響應延遲、連線數等。以下是該命令的輸出示例：
SWA_CLI> status detail
Status as of: Fri Nov 11 14:06:52 2022 +03
Up since: Fri Apr 08 10:15:00 2022 +03 (217d 3h 51m 52s)
System Resource Utilization:
CPU 3.3%
RAM 6.2%
Reporting/Logging Disk 45.6%
Transactions per Second:
Average in last minute 55
Maximum in last hour 201
Average in last hour 65
Maximum since proxy restart 1031
Average since proxy restart 51
Bandwidth (Mbps):
Average in last minute 4.676
Maximum in last hour 327.258
Average in last hour 10.845
Maximum since proxy restart 1581.297
Average since proxy restart 11.167
Response Time (ms):
Average in last minute 635
Maximum in last hour 376209
Average in last hour 605
Maximum since proxy restart 2602943
Average since proxy restart 701
Cache Hit Rate:
Average in last minute 0
Maximum in last hour 2
Average in last hour 0
Maximum since proxy restart 15
Average since proxy restart 0
Connections:
Idle client connections 186
Idle server connections 184
Total client connections 3499
Total server connections 3632
SSLJobs:
In queue Avg in last minute 4
Average in last minute 45214
SSLInfo Average in last min 94
Network Events:
Average in last minute 0.0
Maximum in last minute 35
Network events in last min 124502rate命令顯示有關代理進程使用的CPU百分比的即時資訊，以及每秒請求數(RPS)和快取統計資訊。此命令將繼續輪詢和顯示新輸出，直到中斷。以下是此命令的輸出範例：
SWA_CLI> rate
Press Ctrl-C to stop.
%proxy reqs client server %bw disk disk
CPU /sec hits blocks misses kb/sec kb/sec saved wrs rds
5.00 51 1 147 370 2283 2268 0.6 48 37
4.00 36 0 128 237 21695 21687 0.0 47 38
4.00 48 2 179 307 8168 8154 0.2 65 33
5.00 53 0 161 372 2894 2880 0.5 48 32
6.00 52 0 198 328 15110 15100 0.1 63 33
6.00 77 0 415 363 4695 4684 0.2 48 34
7.00 85 1 417 433 5270 5251 0.4 49 35
7.00 67 1 443 228 2242 2232 0.5 85 44tcpservices命令顯示有關所選進程偵聽埠的資訊。系統還會顯示每個進程以及地址和埠組合的說明：
SWA_CLI> tcpservices
System Processes (Note: All processes may not always be present)
ftpd.main - The FTP daemon
ginetd - The INET daemon
interface - The interface controller for inter-process communication
ipfw - The IP firewall
slapd - The Standalone LDAP daemon
sntpd - The SNTP daemon
sshd - The SSH daemon
syslogd - The system logging daemon
winbindd - The Samba Name Service Switch daemon
Feature Processes
coeuslogd - Main WSA controller
gui - GUI process
hermes - Mail server for sending alerts, etc.
java - Processes for storing and querying Web Tracking data
musd - AnyConnect Secure Mobility server
pacd - PAC file hosting daemon
prox - WSA proxy
trafmon - L4 Traffic Monitor
uds - User Discovery System (Transparent Auth)
wccpd - WCCP daemon
COMMAND USER TYPE NODE NAME
connector root IPv4 TCP 127.0.0.1:8823
java root IPv6 TCP [::127.0.0.1]:18081
hybridd root IPv4 TCP 127.0.0.1:8833
gui root IPv4 TCP 172.16.40.80:8443
ginetd root IPv4 TCP 172.16.40.80:ssh
nginx root IPv6 TCP *:4431
nginx root IPv4 TCP 127.0.0.1:8843
nginx nobody IPv6 TCP *:4431
nginx nobody IPv4 TCP 127.0.0.1:8843
nginx nobody IPv6 TCP *:4431
nginx nobody IPv4 TCP 127.0.0.1:8843
api_serve root IPv4 TCP 172.16.40.80:6080
api_serve root IPv4 TCP 127.0.0.1:60001
api_serve root IPv4 TCP 172.16.40.80:6443
chimera root IPv4 TCP 127.0.0.1:6380
nectar root IPv4 TCP 127.0.0.1:6382
redis-ser root IPv4 TCP 127.0.0.1:6383
redis-ser root IPv4 TCP 127.0.0.1:6379
prox root IPv4 TCP 127.0.0.1:http
prox root IPv6 TCP [::1]:http
prox root IPv4 TCP 172.16.11.69:http
prox root IPv4 TCP 172.16.11.68:http
prox root IPv4 TCP 172.16.11.252:http
prox root IPv4 TCP 127.0.0.1:3128
prox root IPv6 TCP [::1]:3128
prox root IPv4 TCP 172.16.11.69:3128
prox root IPv4 TCP 172.16.11.68:3128
prox root IPv4 TCP 172.16.11.252:3128
prox root IPv4 TCP 127.0.0.1:https
prox root IPv6 TCP [::1]:https
prox root IPv4 TCP 172.16.11.69:https
prox root IPv4 TCP 172.16.11.68:https
prox root IPv4 TCP 172.16.11.252:https
prox root IPv4 TCP 127.0.0.1:http
prox root IPv6 TCP [::1]:http
prox root IPv4 TCP 172.16.11.69:http
prox root IPv4 TCP 172.16.11.68:http
prox root IPv4 TCP 172.16.11.252:http
prox root IPv4 TCP 127.0.0.1:3128
prox root IPv6 TCP [::1]:3128
prox root IPv4 TCP 172.16.11.69:3128
prox root IPv4 TCP 172.16.11.68:3128
prox root IPv4 TCP 172.16.11.252:3128
prox root IPv4 TCP 127.0.0.1:https
prox root IPv6 TCP [::1]:https
prox root IPv4 TCP 172.16.11.69:https
prox root IPv4 TCP 172.16.11.68:https
prox root IPv4 TCP 172.16.11.252:https
prox root IPv4 TCP 127.0.0.1:25255
prox root IPv4 TCP 127.0.0.1:socks
prox root IPv6 TCP [::1]:socks
prox root IPv4 TCP 172.16.11.69:socks
prox root IPv4 TCP 172.16.11.68:socks
prox root IPv4 TCP 172.16.11.252:socks
prox root IPv4 TCP 127.0.0.1:ftp-proxy
prox root IPv6 TCP [::1]:ftp-proxy
prox root IPv4 TCP 172.16.11.69:ftp-proxy
prox root IPv4 TCP 172.16.11.68:ftp-proxy
prox root IPv4 TCP 172.16.11.252:ftp-proxy
prox root IPv4 TCP 127.0.0.1:http
prox root IPv6 TCP [::1]:http
prox root IPv4 TCP 172.16.11.69:http
prox root IPv4 TCP 172.16.11.68:http
prox root IPv4 TCP 172.16.11.252:http
prox root IPv4 TCP 127.0.0.1:3128
prox root IPv6 TCP [::1]:3128
prox root IPv4 TCP 172.16.11.69:3128
prox root IPv4 TCP 172.16.11.68:3128
prox root IPv4 TCP 172.16.11.252:3128
prox root IPv4 TCP 127.0.0.1:https
prox root IPv6 TCP [::1]:https
prox root IPv4 TCP 172.16.11.69:https
prox root IPv4 TCP 172.16.11.68:https
prox root IPv4 TCP 172.16.11.252:https
prox root IPv4 TCP 127.0.0.1:25256
prox root IPv4 TCP 127.0.0.1:http
prox root IPv6 TCP [::1]:http
prox root IPv4 TCP 172.16.11.69:http
prox root IPv4 TCP 172.16.11.68:http
prox root IPv4 TCP 172.16.11.252:http
prox root IPv4 TCP 127.0.0.1:3128
prox root IPv6 TCP [::1]:3128
prox root IPv4 TCP 172.16.11.69:3128
prox root IPv4 TCP 172.16.11.68:3128
prox root IPv4 TCP 172.16.11.252:3128
prox root IPv4 TCP 127.0.0.1:https
prox root IPv6 TCP [::1]:https
prox root IPv4 TCP 172.21.11.69:https
prox root IPv4 TCP 172.21.11.68:https
prox root IPv4 TCP 172.21.11.252:https
prox root IPv4 TCP 127.0.0.1:25257
smart_age root IPv6 TCP [::127.0.0.1]:65501
smart_age root IPv6 TCP [::127.0.0.1]:28073
interface root IPv4 TCP 127.0.0.1:domain
stunnel root IPv4 TCP 127.0.0.1:32137日誌記錄
Web流量具有高度動態性和多樣性。代理部署完成後，定期重新評估通過裝置的流量數量和構成非常重要。您必須定期檢查解密流量的百分比（每季度一次），以確保大小與初始安裝的預期和規格一致。這可以通過日誌管理產品(如高級網路安全報告(AWSR))或訪問日誌的簡單Bash或PowerShell命令來完成。還必須定期重新評估RPS的數量，以確保裝置具有足夠的開銷來應對高可用性、負載均衡配置中的流量高峰和可能的故障切換。
track_stats日誌每五分鐘附加一次，其中包含多個與記憶體中的prox進程及其對象直接相關的輸出部分。在效能監控中最有用的部分是顯示各種請求進程的平均延遲（包括DNS查詢時間、AV引擎掃描時間和許多更有用的欄位）的部分。此日誌不能從GUI或CLI配置，只能通過安全複製協定(SCP)或檔案傳輸協定(FTP)訪問。這是進行效能故障排除時所需的最重要的日誌，因此必須頻繁輪詢。
每個SHD日誌行每60秒寫入一次，其中包含許多對效能監控很重要的欄位，包括延遲、RPS以及客戶端和伺服器端連線總數。以下是SHD日誌行的示例：
Fri Nov 11 14:16:42 2022 Info: Status: CPULd 2.4 DskUtil 45.7 RAMUtil 6.7 Reqs 62 Band 11383 Latency 619 CacheHit 0 CliConn 3817 SrvConn 3804 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:17:42 2022 Info: Status: CPULd 2.6 DskUtil 45.7 RAMUtil 6.7 Reqs 55 Band 10532 Latency 774 CacheHit 0 CliConn 3546 SrvConn 3539 MemBuf 1 SwpPgOut 250467 ProxLd 4 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:18:43 2022 Info: Status: CPULd 1.9 DskUtil 45.7 RAMUtil 6.6 Reqs 48 Band 7285 Latency 579 CacheHit 0 CliConn 3418 SrvConn 3410 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:19:43 2022 Info: Status: CPULd 2.3 DskUtil 45.7 RAMUtil 6.6 Reqs 52 Band 34294 Latency 791 CacheHit 0 CliConn 3605 SrvConn 3586 MemBuf 1 SwpPgOut 250467 ProxLd 4 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:20:43 2022 Info: Status: CPULd 2.4 DskUtil 45.7 RAMUtil 6.7 Reqs 55 Band 8696 Latency 691 CacheHit 0 CliConn 3455 SrvConn 3432 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:21:43 2022 Info: Status: CPULd 2.3 DskUtil 45.7 RAMUtil 6.7 Reqs 49 Band 7064 Latency 1403 CacheHit 0 CliConn 3339 SrvConn 3330 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:22:43 2022 Info: Status: CPULd 1.9 DskUtil 45.7 RAMUtil 6.8 Reqs 41 Band 5444 Latency 788 CacheHit 0 CliConn 3227 SrvConn 3212 MemBuf 1 SwpPgOut 250467 ProxLd 4 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:23:43 2022 Info: Status: CPULd 2.2 DskUtil 45.7 RAMUtil 6.8 Reqs 48 Band 6793 Latency 820 CacheHit 0 CliConn 3280 SrvConn 3265 MemBuf 1 SwpPgOut 250467 ProxLd 3 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:24:44 2022 Info: Status: CPULd 2.3 DskUtil 45.7 RAMUtil 6.7 Reqs 44 Band 8735 Latency 673 CacheHit 0 CliConn 3405 SrvConn 3389 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:25:44 2022 Info: Status: CPULd 2.4 DskUtil 45.7 RAMUtil 6.7 Reqs 53 Band 8338 Latency 731 CacheHit 0 CliConn 3637 SrvConn 3622 MemBuf 1 SwpPgOut 250467 ProxLd 4 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0可以向access_logs新增其他自定義欄位，這些欄位表示單個請求的延遲資訊。這些欄位包括伺服器響應、DNS解析和AV掃描器延遲。這些欄位必須新增到日誌中，以收集用於故障排除的重要資訊。這是推薦使用的自定義欄位字串：
[ Request Details: ID = %I, User Agent = %u, AD Group Memberships = ( %m ) %g ] [ Tx Wait Times (in ms): 1st byte to server = %:<1, Request Header = %:
, Response Header = %:h>, Client Body = %:b> ] [ Rx Wait Times (in ms): 1st request byte = %:1<, Request Header = %:h<, Client Body = %:b<, 1st response byte = %:>1, Response header = %:>h, Server response = %:>b, Disk Cache = %:>c; Auth response = %:
a; DNS response = %:
d, WBRS response = %:
r, AVC response = %:A>, AVC total = %:A<, DCA response = %:C>, DCA total = %:C<, McAfee response = %:m>, McAfee total = %:m<, Sophos response = %:p>, Sophos total = %:p<, Webroot response = %:w>, Webroot total = %:w<, Anti-Spyware response = %:
s, AMP response = %:e>, AMP total = %:e<; Latency = %x; %L ][Client Port = %F, Server IP = %k, Server Port = %p]
從這些值匯出的效能資訊如下：
| 自定義欄位 | 說明 |
| %:<a | 在Web代理傳送請求後，等待從Web代理身份驗證進程接收響應的時間。 |
| %:<b | 在標頭之後將請求正文寫入伺服器的等待時間。 |
| %:<d | 在Web代理傳送請求後，等待從Web代理DNS進程接收響應的時間。 |
| %:<h | 在第一個位元組之後將請求報頭寫入伺服器的等待時間。 |
| %:<r | Web代理傳送請求後，等待從Web信譽過濾器接收響應的時間。 |
| %:<s | 在Web代理傳送請求後，等待從Web代理反間諜軟體進程接收判定結果的時間。 |
| %:> | 等待伺服器第一個響應位元組的時間。 |
| %:>a | 從Web代理身份驗證過程接收響應的等待時間，包括Web代理傳送請求所需的時間。 |
| %:>b | 收到標頭後等待完成響應正文的時間。 |
| %:>c | Web代理從磁碟快取讀取響應所需的時間。 |
| %:>d | 從Web代理DNS進程接收響應的等待時間，包括Web代理傳送請求所需的時間。 |
| %:>h | 第一個響應位元組之後的伺服器報頭的等待時間。 |
| %:>r | 從Web信譽過濾器接收判定結果的等待時間，包括Web代理傳送請求所需的時間。 |
| %:>s | 從Web代理反間諜軟體進程接收判定結果的等待時間，包括Web代理傳送請求所需的時間。 |
| %:1< | 等待新客戶端連線的第一個請求位元組的時間。 |
| %:1> | 寫入客戶端的第一個位元組的等待時間。 |
| %:b< | 等待完整的客戶端正文。 |
| %:b> | 寫入客戶端的完整正文等待時間。 |
| %:e> | 在Web代理傳送請求後，等待從AMP掃描引擎接收響應的時間。 |
| %:e< |
從AMP掃描引擎接收判定結果的等待時間，包括Web代理傳送請求所需的時間。 |
| %:h< | 第一個位元組後等待完成客戶端報頭的等待時間。 |
| %:h> | 寫入客戶端的完整報頭等待時間。 |
| %:m< | 從McAfee掃描引擎接收判定結果的等待時間，包括Web代理傳送請求所需的時間。 |
| %:m> | 在Web代理傳送請求後，等待時間以接收來自McAfee掃描引擎的響應。 |
| %F | 客戶端源埠。 |
| %p | Web伺服器埠。 |
| %k | 資料來源IP地址（Web伺服器IP地址）。 |
| %:w< | 從Webroot掃描引擎接收判定結果的等待時間，包括Web代理傳送請求所需的時間。 |
| %:w> | 在Web代理傳送請求後，等待從Webroot掃描引擎接收響應的時間。 |
SWA許可模式允許對虛擬裝置重複使用物理裝置許可證。您可以利用此優勢並部署測試SWAv裝置，以便在實驗室環境中使用。新功能和配置可以通過這種方式進行試用，以確保穩定性和可靠性，同時不會違反許可條款。
進階網路安全報告(AWSR)
必須利用AWSR來從SWA中充分利用報告資料。特別是在部署了許多SWA的環境中，此解決方案的可擴充性比在安全管理設備(SMA)上使用集中報告要高許多倍，並且提供了定製報告屬性，為資料增加了極大的深度和定製性。可以對報告進行分組和自定義，以滿足任何組織的需求。在確定AWSR的規模時必須使用Cisco Advanced Services組。
電子郵件警報
最好將SWA上的內建電子郵件警報系統用作基本警報系統。必須對其進行適當調整以滿足管理員的需要，因為如果所有資訊性事件都啟用，可能會引起很大的噪音。限制警報並主動監視警報比對所有警報都發出警報並將其視為垃圾郵件更重要。
| 警報設定 | 組態 |
| 傳送警報時要使用的發件人地址 | 自動生成 |
| 傳送重複警報之前等待的初始秒數 | 300秒 |
| 傳送重複警報之前等待的最大秒數 | 3600秒 |
可用性監控
有兩種方法可用於監控Web代理的可用性。第一個是第3層(L3)監控，用於測試裝置在網路上是否可以訪問IP地址。測試此情況的最簡單方法是定期向位址傳送ICMP回應(ping)請求，並檢查回覆封包。可以分析應答的屬性（如TTL和延遲）以確定網路層的運行狀況。
裝置可能會響應ping，但代理進程沒有響應或間歇性中斷。因此，建議使用第7層(L7)監控器，該監控器會向裝置傳送顯式代理請求，並需要200 OK HTTP響應代碼。這不僅測試網路介面的可達性，而且測試代理服務的響應性，以及在請求外部資源時測試上游服務的可行性。此類監控通常採用請求代理連線到資源的顯式HTTP HEAD請求的形式。HEAD方法請求將返回的標頭，客戶端必須傳送GET請求，但僅包括響應標頭而不包括資料。
如果您使用L7監控工具或指令碼，請確保流量免於身份驗證非常重要。否則會導致定期身份驗證失敗和資源消耗。在監控工具中使用自定義使用者代理字串時，必須採用它來標識流量。即使流量無需身份驗證，仍可通過訪問策略限制其不必要地訪問Internet。
當您使用其中一種或多種方法時，管理員必須圍繞代理響應建立可接受度量的基準，並使用該基準構建警報閾值。您必須將時間用於收集此類檢查的響應，然後才能決定如何配置閾值和警報。
SNMP監控
簡單網路管理協定(SNMP)是監控裝置運行狀況的主要方法。它可用於接收來自裝置的警報（陷阱）或輪詢各種對象識別符號(OID)以收集資訊。SWA上有許多OID涵蓋從硬體到資源使用到單個流程資訊和請求統計的所有內容。
出於硬體和效能相關原因，必須監控許多特定的電腦資訊庫(MIB)。MIB的完整清單可在此處找到：https://www.cisco.com/web/ironport/tools/web/asyncosweb-mib.txt。
這是要監控的建議MIB的清單，而不是詳盡的清單：
| 硬體OID | 名稱 |
| 1.3.6.1.4.1.15497.1.1.1.18.1.3 | raidID |
| 1.3.6.1.4.1.15497.1.1.1.18.1.2 | raid狀態 |
| 1.3.6.1.4.1.15497.1.1.1.18.1.4 | raidLastError |
| 1.3.6.1.4.1.15497.1.1.1.10 | 風扇表 |
| 1.3.6.1.4.1.15497.1.1.1.9.1.2 | 攝氏度 |
這是OID直接對映到status detail CLI命令的輸出：
| OID | 名稱 | 狀態詳細資訊欄位 |
| 系統資源 | ||
| 1.3.6.1.4.1.15497.1.1.1.2.0 | 百分之CPU利用率 | CPU |
| 1.3.6.1.4.1.15497.1.1.1.1.0 | 記憶體利用率百分比 | RAM |
| 每秒交易數 | ||
| 1.3.6.1.4.1.15497.1.2.3.7.1.1.0 | cacheThruputNow | 最後一分鐘每秒平均事務數。 |
| 1.3.6.1.4.1.15497.1.2.3.7.1.2.0 | cacheThruput1hrPeak | 上一小時每秒的最大事務數。 |
| 1.3.6.1.4.1.15497.1.2.3.7.1.3.0 | cacheThruput1hrMean | 上一小時每秒平均事務數。 |
| 1.3.6.1.4.1.15497.1.2.3.7.1.8.0 | cacheThruputLifePeak | 代理重新啟動後每秒最大事務數。 |
| 1.3.6.1.4.1.15497.1.2.3.7.1.9.0 | cacheThruLifeMean | 代理重新啟動後每秒平均事務數。 |
| 頻寬 | ||
| 1.3.6.1.4.1.15497.1.2.3.7.4.1.0 | cacheBwidthTotalNow | 最後一分鐘的平均頻寬。 |
| 1.3.6.1.4.1.15497.1.2.3.7.4.2.0 | cacheBwidthTotal1hrPeak | 過去一小時內的最大頻寬。 |
| 1.3.6.1.4.1.15497.1.2.3.7.4.3.0 | cacheBwidthTotal1hrMean | 過去一小時內的平均頻寬。 |
| 1.3.6.1.4.1.15497.1.2.3.7.4.8.0 | cacheBwidthTotalLifePeak | 自代理重新啟動以來的最大頻寬。 |
| 1.3.6.1.4.1.15497.1.2.3.7.4.9.0 | cacheBwidthTotalLifeMean | 代理重新啟動後的平均頻寬。 |
| 響應時間 | ||
| 1.3.6.1.4.1.15497.1.2.3.7.9.1.0 | cacheHitsNow | 上一分鐘的平均快取命中率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.9.2.0 | cacheHits1hrPeak | 上一小時的最大快取命中率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.9.3.0 | cacheHits1hrMean | 過去一小時內的平均快取記憶體命中率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.9.8.0 | cacheHits生命峰值 | 自代理重新啟動以來的最大快取命中率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.9.9.0 | cacheHits生命平均值 | 自代理重新啟動以來的平均快取命中率。 |
| 快取命中率 | ||
| 1.3.6.1.4.1.15497.1.2.3.7.5.1.0 | cacheHitsNow | 上一分鐘的平均快取命中率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.5.2.0 | cacheHits1hrPeak | 上一小時的最大快取命中率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.5.3.0 | cacheHits1hrMean | 過去一小時內的平均快取記憶體命中率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.5.8.0 | cacheHits生命峰值 | 自代理重新啟動以來的最大快取命中率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.5.9.0 | cacheHits生命平均值 | 自代理重新啟動以來的平均快取命中率。 |
| 連線 | ||
| 1.3.6.1.4.1.15497.1.2.3.2.7.0 | cacheClientIdleConns | 空閒客戶端連線。 |
| 1.3.6.1.4.1.15497.1.2.3.3.7.0 | cacheServerIdleConns | 空閒伺服器連線。 |
| 1.3.6.1.4.1.15497.1.2.3.2.8.0 | cacheClientTotalConns | 客戶端連線總數。 |
| 1.3.6.1.4.1.15497.1.2.3.3.8.0 | cacheServerTotalConns | 伺服器連線總數。 |
結論
本指南旨在介紹SWA配置、部署和監控的最重要方面。作為參考指南，它的目標是為那些希望確保最有效地使用全部門辦法的人提供有價值的資訊。這裡介紹的最佳實踐對於裝置作為安全工具的穩定性、可擴充性和有效性非常重要。它還尋求隨著相關資源的不斷發展而繼續保留，因此必須頻繁更新，以反映網路環境和產品功能集的變化。
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
3.0 |
25-Jul-2023 |
初始版本 |
1.0 |
10-Apr-2023 |
初始版本 |
意見