資安，真的會造成對立嗎？

 

有時候，我總覺得資安就像那個家裡的「防盜門」，一開始大家覺得多此一舉，但一旦用上就知道不裝不行；然而在裝的過程中，總是有人抱怨「幹嘛這麼麻煩？」。職場上的資安，好像也差不多。

沒資安人員前：對外能用就好，稽核過關就好

還記得公司還沒有資安人員進駐的時候，整個IT團隊都抱著「能用就好」的心態。
系統能讓客戶連上線、資料能夠順利跑完流程、Email 可以寄出收進來，基本上就是合格了。至於稽核？只要偶爾整理一下紀錄、檢查一下權限，看起來「表面乾淨整齊」，稽核官來檢查也能點頭說：「嗯，可以過。」

那個階段，大家對資安的感覺很簡單：

• 防火牆？開著就好。

• SSL 證書？不要過期就好。

• 使用者權限？能登入能操作就好。

總之，只要對外能用，內部同事操作不被卡到，稽核能過關，一切就算完成任務。

那時候的我們，根本還沒有遇到資安人員。大家的心態大概是：「資安？等會有人來管就好了。」

資安人員來了：安全 VS 可用，好像開始對立

事情開始轉折，是在應用程式人員想開通某些外對內服務的時候。原本只要「能用」就好了，但資安人員出現後，情況完全變了。

你申請一個端口開放？資安人員開始計算風險、考慮潛在攻擊面。
你想部署一個 API 對外？資安人員會要求加驗證、加日誌、加加密，甚至提醒「這個還可能被 XX 攻擊」。

突然間，原本簡單的需求，變得像是過五關斬六將。大家會開始覺得：「幹嘛要這麼麻煩？我只是想讓客戶能用啊！」
私下裡，抱怨聲此起彼落。應用程式人員說：「資安人員就是來拆我的需求！」
資安人員心裡想：「他們懂什麼是安全？都只會想著好用！」

就這樣，一個小小的功能開通申請，瞬間演變成職場小戰爭，雙方好像天生就是對立的。

我本人對資安的初體驗：從抗拒到習慣

老實說，我自己也不是資安出身。以前提到資安，我的心裡是：「啊…又要學一堆東西嗎？」
尤其是當客戶要求必須達到某些資安檢查標準的時候，我一開始完全抗拒。

想想那些東西：

• SSL 憑證要檢查，還要知道什麼是中間憑證、根憑證。

• 網頁安全要調整，防 XSS、防 CSRF、防 SQL Injection。

• 權限管理要檢查，每個帳號都有什麼權限、誰能改誰不能改。

天啊！這些以前完全不熟的東西，突然要我搞懂還要落實，真的是一開始覺得心裡打鼓、手腳發抖。

但後來，我逼自己去看文件、查資料，甚至實際操作了一遍，結果發現…只要按步驟做，其實並沒有想像中恐怖。
最終，我達到客戶要求的資安最低標準，雖然不是滿分，但至少符合規範，也算是一種成就感。

更重要的是，這個過程變成了經驗累積。下次遇到類似需求，我就不會再慌張，因為我知道要檢查哪些、要調整哪些、要注意哪些細節。

所以，資安學起來，不只保護系統，也保護自己。這種「以不變應萬變」的心態，對職場生存很有幫助。

資安不是資安人的責任，而是全公司的責任

這點我深深體會到：資安不能只是資安人員的事情。
如果公司上下都沒有資安意識，再強的資安團隊也只能像「孤軍奮戰」，結果往往是疲於奔命、被抱怨、甚至被孤立。

我認為，要把資安導入公司，有幾個前提：

1. 老闆要支持
   如果老闆不支持資安策略，資安人員在公司就像走鋼索，一不小心就被人咬耳朵、被排擠、甚至被標黑。
   老闆的態度會決定資安在公司內部的定位：是「戰略核心」還是「麻煩製造者」。

2. 全公司都有責任
   資安不是資安團隊的專利，應用程式人員、系統管理員、業務部門、甚至行政部門都應該參與。
   這樣一來，當資安人員提出需求時，不會只聽到抱怨，而是理解「這是保護公司、保護客戶、保護自己」。

3. 教育和經驗累積
   不可能每個人一開始就熟悉資安，但可以透過訓練和實務操作，慢慢建立經驗。
   就像我自己，雖然初期抗拒，但累積經驗後就能從容應對，甚至可以幫助團隊提升整體資安水平。

職場幽默小觀察

我發現，資安造成的「對立感」其實有點像職場的「愛恨交錯」：

• 應用程式人員抱怨資安人員太嚴格，但其實心底也希望系統不被攻擊。

• 資安人員抱怨大家不懂安全，但看到系統被保護起來時，也會暗自竊喜。

• 老闆覺得資安很麻煩，但一旦出了問題，第一個被問責的還是自己。

所以，資安的對立感，其實更多是角色定位的衝突，而不是人人天生敵對。

我常開玩笑說，資安就像吃蔬菜：一開始嫌棄、覺得麻煩，但吃過幾次、感受到健康好處後，你就會慢慢欣賞它。

總結：資安其實可以是一種「職場成長的契機」

回過頭來看，資安的存在並非為了製造對立，而是保護公司、保護客戶、保護自己。

• 沒資安時，大家覺得簡單、方便，但風險潛藏。

• 有資安時，看似對立，其實是不同角色在不同角度思考。

• 個人學習資安，能累積經驗、增加面對挑戰的自信。

• 導入資安，需要老闆支持與全公司參與，才能避免孤立與抱怨。

所以，下次當應用程式人員抱怨「資安太麻煩」或資安人員皺眉「大家都不懂安全」時，不妨幽默地想想：這是職場的必經過程，也是每個人進步的契機。

資安，不是對立，而是成長。

而且，說不定有一天，你會發現，那些曾經抱怨的麻煩要求，其實都是你未來職場生存的「防彈衣」。

PaloAlto_21 Security Policy 不是 allow any

 

開場白：allow any 是工程師的泡麵

凌晨兩點、專案卡關、客戶在催、系統就是不通。
這時候，最容易出現的一行設定就是：

Source：any
Destination：any
Service：any
Action：allow

它就像泡麵——
不健康、沒營養、但「立刻可以活下來」。

但在 Palo Alto Networks 的世界裡，
Security Policy 的存在，就是為了阻止你每天吃泡麵。

第一課：Security Policy 到底在管什麼？

先講人話版本：
Security Policy = 誰，可以，在什麼情況下，用什麼方式，跟誰說話。

工程師翻譯版是五個 W：

1. Who（Source）：誰發起連線

2. To Whom（Destination）：要連到哪

3. How（Application / Service）：用什麼方式

4. When（Schedule）：什麼時間

5. So What（Action）：放行 or 擋掉

allow any 等於直接跟防火牆說：

「你不要思考，我來承擔後果。」
（歷史證明，後果通常你也承擔不起）

第二課：為什麼 Palo Alto 討厭 allow any？

因為 Palo Alto 的核心哲學只有一句話：

「我不只看 port，我看你在幹嘛。」

傳統防火牆：

• TCP/443？好，大概是 HTTPS，放。

Palo Alto：

• TCP/443？

• 是 HTTPS？

• 還是 Dropbox？

• 還是某個你不想讓老闆知道的東西？

你如果用 allow any，等於買了跑車卻永遠踩一檔。

第三課：正確的 Policy 心法

1️⃣ 先想「業務需求」，不是先想「怎麼通」

錯誤流程：

ping 不通 → allow any → 世界和平（10 分鐘）

正確流程：

這台 Server 要做什麼？
它應該跟誰說話？

Security Policy 是白名單思維，不是黑名單懺悔錄。

2️⃣ App-ID 是你的好朋友，不是麻煩鬼

很多人抱怨：

「App-ID 很煩，規則寫不動。」

但實話是：
App-ID 是幫你把『不知道自己在幹嘛』變成『我很清楚』。

實務建議：

• 能用 Application，就不要只用 Service

• HTTPS ≠ 一切合法行為

3️⃣ Rule Order：防火牆是從上往下讀的

這不是小說，沒有伏筆。

• 第一條 match，就停

• allow any 放最上面 = 所有規則都是裝飾品

工程師金句：

「規則不是沒生效，是你永遠跑不到它。」

第四課：一個「不丟臉」的 Security Policy 教學範例

假設情境：

Web Server 需要對外提供 HTTPS

錯誤寫法（資安會皺眉）：

• Source：any

• Destination：Web Server

• Service：any

• Action：allow

比較像樣的寫法：

• Source：Internet Zone

• Destination：Web Server Zone

• Application：ssl, web-browsing

• Service：application-default

• Action：allow

這時候 Palo Alto 會說：

「好，我知道你在做網站，不是在亂來。」

第五課：Log 不看，比 allow any 更可怕

很多人寫完規則就收工，
Log 的存在彷彿只是為了佔硬碟。

但事實是：

• Log = 你未來自保的證據

• Log = 你跟資安、稽核、老闆溝通的翻譯機

至少做到三件事：

1. 允許的流量要記錄

2. 被擋的流量要敢看

3. 出事時不要第一句就說「防火牆沒動」

結語：allow any 不是原罪，但是警訊

老實說，每個工程師人生中都用過 allow any。
真正的差別在於：

• 新手：用了就忘

• 老手：用了會內疚，然後刪掉

Security Policy 的成熟度，
不是你會不會寫 allow any，
而是你能不能不用它，系統還是活得好好的。

如果你現在打開 Palo Alto，
看到某條 allow any 在角落對你微笑——
別怕，
它不是在嘲笑你，
它是在等你長大。

PaloAlto_20 的 Routing & NAT

 

一場封包的迷航記，以及工程師的自我修行

如果你第一次打開 Palo Alto Networks Firewall，大概會有一種感覺：
「介面好漂亮。」
三分鐘後：
「Routing 跑去哪？」
十分鐘後：
「為什麼 NAT 看起來像在玩邏輯題？」

放心，你不是一個人。
在 PaloAlto_20（泛指 PA 防火牆 10.x 世代設定邏輯）裡，Routing 與 NAT 從來不是單純的「網路設定」，而是一場工程師心智成熟度測驗。

一、Routing：不是幫你指路，是決定你的人生方向

在工程師的世界裡，Routing 就像人生規劃。
你以為只要設定一條 Default Route（0.0.0.0/0），封包就會自動走向幸福的彼岸。
但 Palo Alto 冷冷地告訴你一句話：

「不好意思，我要先看 Virtual Router。」

是的，Palo Alto 沒有「全域 Routing Table」，
每個 Interface 都要掛在正確的 Virtual Router 底下，
否則你的封包會陷入量子狀態——
介於「送出」與「消失」之間。

工程師常見錯誤清單：

• Interface 掛錯 Virtual Router

• 靜態路由寫得很美，但根本沒人用

• OSPF 開得很開心，對面根本沒鄰居

這時候你會學到 Palo Alto 的第一堂人生課：
👉 Routing 沒錯，只是你想得太天真。

二、NAT：封包的變裝秀，比你想得更複雜

如果 Routing 是人生方向，那 NAT 就是身分證改名大賽。

在 Palo Alto 裡，NAT 不是「順手設定一下」，
而是明確告訴你：
「我什麼時候要改你、在哪裡改你、改成什麼樣子。」

Palo Alto 的 NAT 三大靈魂問題：

1. Original Packet 長怎樣？

2. Translated Packet 要變成誰？

3. 這一切發生在 Security Policy 之前，還是之後？

很多新手工程師會天真地問：
「為什麼我 NAT 設好了，還是連不上？」

答案通常只有一句：
👉 因為你的 Security Policy 根本不是用 NAT 後的 IP 在比對。

這一刻，你會突然理解為什麼資深工程師都不愛說話。
不是冷漠，是已經痛過。

三、Routing × NAT：當兩個世界開始互相傷害

真正的修羅場，是 Routing 跟 NAT 同時出問題。

經典場景如下：

• 封包進來 → Routing 看得懂

• NAT 改得很開心

• 封包出去 → Routing 說「這不是我認識的你」

然後 Session 就這樣死在 Log 裡，
留下你一個人盯著 Monitor → Traffic，看著封包的最後一跳。

這時候你會開始做工程師的三大儀式：

1. 開 Packet Capture

2. 打開 CLI 看 test routing fib-lookup

3. 默默懷疑人生選擇

四、工程師的覺醒：你終於開始「看流程」

某一天，你突然不再亂改設定了。

你會開始照流程思考：

1. 封包從哪個 Interface 進來？

2. 屬於哪個 Zone？

3. Routing 決定往哪走？

4. NAT 什麼時候介入？

5. Security Policy 用的是哪個 IP？

6. 回程路由是不是對稱？

那一刻，你不會特別開心，
但你會很平靜地說一句話：

「嗯，這個我大概知道問題在哪。」

恭喜你，你已經從「亂試工程師」
進化成「有邏輯的工程師」。

五、結語：Palo Alto 沒有很難，只是很誠實

PaloAlto_20 的 Routing & NAT，
其實沒有陷阱、沒有魔法、也沒有黑箱。

它只是把網路的本質攤開來，
逼你面對現實。

如果你哪天設定完，
封包一次就通，Log 乾乾淨淨，
那不是因為運氣好——

而是因為你已經學會用工程師的方式思考。

最後送你一句 Palo Alto 生存守則：

「Routing 決定你去哪，NAT 決定你是誰。」

而工程師，決定要不要再加班。