終於來到了最後，前面鋪陳的很多劇情或是意外，都是真實發生在不同公司身上的狀況。
就如同DAY-28 提到的「不是問題的都變成問題了」，CDN商大多會嚴格遵守各項技術RFC的標準，與大家工作上對於可以通就好有很大的落差，最後就產生不如預期的意外。
其實，這次分享的還不到實務上的1/10，主要是因為行業及對效能上的要求不同，面臨的技術挑戰也不同。
這篇純粹以導入CDN防護為主軸，有不少技術的細節實例都需要直接看攻擊資料做解釋，但這些都會牽涉到機敏的資料，所以還只能很皮毛的跟大家說明設定注意事項。
接下來的說明，將依據個人的經驗以CDN防護為導入主軸，依據CDN導入前、導入中、導入後相關注意事項，提供大家一些評估的依據。
導入前評估
服務網路環境
因應CDN Reverse Proxy架構關係，所有依據來源IP進行防護或導流的網路機制，都要確認是否可以因應調整，包含:
防火牆 : 如有限制來源IP存取的服務，需要將此存取條件改由CDN防火牆機制提供，原有防火牆Policy改為僅能CDN主機之網段可以存取。
伺服主機負載均衡設備 :確認是否支援憑證解密，並可解讀HTTP Header欄位內容，以及Persistence機制並支援Cookie method，以確保交易服務能正常運作。此外，也會需要了解目前設備TCP-idle-timeout的相關設定，以利後續的設定調整。
服務對外開放是IPV4 還是 IPV6，或是同時都需要開放。
服務對外開放的Port，如果不是HTTP標準的80/443，請務必與你的CDN商確認，可以支援那些Port。
牽扯未來CDN串接源站，或是DNS防護等高可用性架構，請廠商協助對你的DNS服務及設備確認，後續的CDN導入作業是否都能配合。
調查整體服務需要的網路流量，建議初次可以稍微寬鬆一點，超量費的每GB價格一定會比較高。
服務型態與系統環境資訊
因應導入服務性質不同，關於服務型態，與系統交易等請求逾時時間，以及CDN架構特性等都要先調查相關資訊，包含:
調查網站動靜態功能及物件提供的型態，並了解其業務屬性包含提供服務的對象，以及會利用那些軟體來存取的形式，例如是瀏覽器或是行動裝置APP。
調查網站平台是透過哪一種WEB 伺服器例如Nginx、Apache、IIS、Tomcat等，TCP idle-timeout為何?
調查是否有特定服務及功能，需要有較長的後端運算時間，因此需要設定較長的idle-timeout時間。
調查允許存取的HTTP Method為何。
憑證相關的資訊，包含到期的時間、類型、等級等。若是金融單位則需要注意法規要求，並請確認對外WHOIS域名聯繫資訊是否正確，以利後續的申請。
調查是否有合作廠商或客戶，是透過直連IP不以Domain形式連接服務。確認這項資訊資訊是為了確保後續開啟防火牆僅能由CDN連線時，不會阻擋到這類型的請求。
快取設定需求
因應導入服務性質不同，關於靜態物件快取機制，需要事先了解以利規劃，包含:
調查現有網站服務是否有提供快取的機制，後續導入CDN防護時，由誰來控制快取的設定。(不建議同時存在，CDN快取機制會失效)
調查網站內容中，可以被快取的檔案類型/路徑 ; 若可以快取，可以設定的天數。
調查需要被快取且檔案容量大於1MB的檔案類型/路徑 ; 或是多媒體如影片廣告等檔案類型/路徑。
網站內容中，不能被快取的檔案類型/路徑。
安全防護需求
因應購買的防護機制不同，需要事先了解以利規劃，包含:
若有DNS防禦機制，調查既有DNS服務的設備型號或軟體名稱與版本，並依據Primary、Secondary ZONE佈署架構，以及DNSSEC等設定規劃需求，尋求專業廠商的協助。
務必確認是否有提供CDN來源IP及網段相關資訊，以利ISP及地端防護設備可以協同設定。
既有網站對於請求Method中特別是GET以及POST，調查尖離峰的閥值以利後續防禦機制中請求頻率的初始設定。
憑證Cipher強度要求，包含TLS版本、Cipher強度要求等。
流量及防護日誌紀錄需要哪些資訊，以及可能需要的儲存日誌空間，建議初期擺放空間可以大點，以利分析。
導入中設定
服務網路環境
網路負載均衡設備 :CDN連接源站服務所採用的方式為FQDN或是IP，請依據服務的高可用性進行規劃。
伺服主機負載均衡設備 :針對導入CDN的服務其HTTP Profile中，設定TCP-idle-timeout為301秒。並將地端憑證導入於伺服主機負載均衡設備中，設定依據CDN提供的真實來源IP欄位進行負載均衡設定，
服務主機系統設定
WEB主機設定TCP-idle-timeout為301秒。
WEB主機及AP等相關服務架構上，依據來源IP進行辨識的機制或程式都須要進行調整，可以依據CDN真實來源IP欄位抓到正常的真實使用者IP。
地端安全防護機制 :
若有ISP流量清洗機制，請將CDN來源網段加入防護排除清單。
若有地端防護機制是以偵測頻率請求為主，請將CDN來源網段加入防護排除清單。
WAF設備設定抓取CDN真實來源IP欄位，上線前務必確認清楚。
導入CDN防護之網站，請用防火牆縣控管僅有CDN來源可存取。
CDN平台設定-站台服務部分 :
CDN連回源站若採FQDN的方式，建議可採亂數方式命名例如urjgsxzdfcgh.lekuza.com，降低遭駭客暴力破解網域，找到源站入口IP的機率。
CDN連回源站的憑證，務必請請協力廠商檢查該憑證是否有在CDN相容清單中，避免HTTPS連線的異常。
真實IP的欄位建議調整名稱，不要使用預設值。
盡量利用CDN的資源優勢，降低源站資源消耗例如:
快取設定，若對初始導入快取沒有想法，可以先全站no store進行。待後續導入可透過平台分析機制，與開發同仁確定快取策略後，再逐步設定。
參考【Day24】上線前的救命仙丹~~監控告警設定 設定告警，並確認寄發的對象能夠協同處理告警。
CDN平台設定-防護機制部分 :
防護策略該怎麼制定，已經都在前面說明過可參考DAY-16~23的相關文章，這邊要提醒的是一些踩過的坑
【Day17】 Akamai AAP 防護機制說明
【Day18】 IP & GEO防火牆-防護機制與策略說明
【Day19】 DDoS分散式防護-防護機制與策略說明
【Day20】自訂客製化規則-防護機制與策略說明
【Day21】Web應用程序防火墻-防護機制與策略說明
【Day22】機器人爬蟲防護-防護機制與策略說明
【Day23】上線前防護機制的調整
Akamai平台上的Match Criteria條件，只能做AND無法做OR的，也就是所有條件都要滿足才會生效。
Rate Thresholds 請求頻率不是萬靈丹，請搭配機器人防護以及自訂客製化規則，降低誤擋也提高防護準確度。
若有人任何條件式針對VPS主機商ASN或是國家GEO進行設定，請務必考量近年流行的如SurfShark、Nord VPN服務。這些服務的主機同樣會架設在這些VPS商，因此若阻擋這些來源，一定會導致部分使用者的誤擋。
平心而論，如果貴司非常在意客訴，一丁點都不能發生，哪麼請以不誤擋的策略為主。但可以準備一個以保護服務為主的防護策略，該策略允許少部分流量遭到誤擋，這個在發生大型攻擊時可以拿出來用而不被罵。
要注意機器人防護中，API流量是不可能進行互動挑戰的，所以當網站混合了API及HTML流量時，務必小心機器人的策略擋住正常流量。
導入後維運
hits by response :這個是統計從使用者端請求送到CDN主機，以及CDN主機轉送到源站，針對HTTP Status的統計。理論上應該2xx跟3xx會比較多，但如果4xx及5xx有增加的趨勢，就應該要進行深度分析，理解原因。
如果是0XX變多，那也要注意為何源站無回應的異常數量變多，以及發生時間點可能會是網路設備、系統主機等造成的，增加後續除錯的效率。
觀察hits跟bytes以及Offload(快取率)之間的關係，只要Offload代表一定會回源站進行請求，而這類的而這類的物件如果hits跟bytes又很高，則源站的負載就會高。因此，定期分析3者之間的關係就會清楚的知道，從效能或是或是防禦的角度上，要如何調整規則降低源站的負擔。
密切注意Origin Connection Failure這條告警，只要不是地端防護機制的誤擋，這條告警出現的頻率可以作為服務穩定度參考。簡單的說，極有可能就是你的網站本身就不穩定，但導入CDN後就可能被拿來當擋箭牌，說都是CDN的問題。
當ISP流量清洗機制封鎖境外流量時，極有可能CDN服務會被影響。因為CDN商的網路運作，只要不是自己拉海纜來的，都要跟ISP商租用頻寬，當額度不夠時就會將使用者流量丟出去境外再回來!!
要注意的事項真的是太多，所以寫不完啦，找對廠商幫你導入比較重要!!
最後的DAY-30，就來聊聊關於CDN產品的選擇以及一些常見的QA囉!! 明天見!!
iThome鐵人賽
看影片追技術