楠梓一位走在前頭的房東，把旗下十來間套房一次到位地「智慧化」——每間裝了智慧電子鎖，配電箱換上可遠端讀值的智慧電表，浴室與陽台各埋一顆漏水感測器，連冷氣都能用手機開關。他很得意，招租廣告打上「智慧租屋」，租客看了眼睛一亮。直到某天，一位在園區做資安的房客盯著牆上的感測器，淡淡問了一句：「這些東西，跟我手機是同一個網路嗎？」房東點頭。房客接著說：「那萬一其中一顆感測器有漏洞被打進來，攻擊者就能從它跳到我的手機、我的筆電上。」房東當場愣住——他從沒想過，裝愈多智慧設備，等於在牆上多開了幾道看不見的門。
先認清一件事：IoT 裝置天生「體弱」
智慧門鎖、感測器與網路攝影機的硬體資源、更新週期和廠商維護能力差異很大，有些產品很快停止更新，也有產品具備簽章更新與長期支援。採購時不要只看功能與價格，要確認支援年限、韌體簽章、弱點通報與停止支援政策；上線後建立版本清冊，無法更新的裝置就隔離或汰換。這比引用沒有樣本說明的「六成事件來自未更新」更能落地。
弱密碼、預設密碼與寫死的管理憑證，一直是 IoT 的重要風險。不要假設新設備一定會強迫改密碼，也不要引用沒有查核日期的「兩成裝置仍用預設帳密」。安裝時逐台確認是否需 activation、改成唯一密碼、停用不需要的 Telnet／UPnP／遠端管理，能用 MFA 或憑證時就啟用。
Mirai 的教訓很清楚：攻擊者會自動掃描公開的 Telnet／SSH，再用常見帳密接管設備，最後把大量 IoT 組成殭屍網路。數量會因研究口徑不同，不影響處理原則：管理服務不直接開到 WAN、每台使用唯一密碼、持續更新，並把 IoT、住戶與管理網分開。
智慧門鎖：方便的背面，是實體安全
所有 IoT 裝置裡，智慧門鎖是最需要另眼看待的一個，因為它直接管的是「門開不開」這件事——出事就是實體世界的損失。它多半靠藍牙（BLE）、Zigbee、Z-Wave 這類低功耗無線協定跟手機或閘道器溝通，而這些協定的安全性，學界翻來覆去驗過很多次。有一份針對十八款市售 BLE 智慧鎖的研究，結論是其中十四款仍可被攻破，牽連的使用者超過兩千萬。手法還不只一種：有的利用配對時圖方便採用的「Just Works」模式去做中間人與冒名（BLE 欺騙攻擊 BLESA 就是一例），有的鑽協定可以重複配對的漏洞，把金鑰硬生生重置掉，Zigbee 這邊甚至出過整個生態系主金鑰外洩的事件。
還有一層常被忽略的風險，是雲端相依。很多智慧鎖的「遠端開門」「臨時密碼」都得繞一圈原廠雲端。2024 年就有一起短租房案例，攻擊者利用一台沒更新的舊韌體鎖，摸進了管理後台，直接改掉門鎖密碼、把整間屋子搬空。這帶出幾條該白紙黑字寫進採購規格的工程準則：門鎖一定要有機械鑰匙或離線備援，斷網、斷雲、沒電時人進得去、也鎖得上；要有低電量預警；原廠的韌體支援年限，要當成選型的硬指標，而不是拿來加分的配菜。
網段隔離到底在隔什麼：把 VLAN 講清楚
面對這一群「體弱又愛闖禍」的裝置，業界的標準解法是網段隔離——把 IoT 裝置圈進一個專屬的虛擬區網（VLAN），跟住戶網段、跟門禁與管理網段各走各的。它的原理是在網路的第二層（也就是交換器這一層）就把不同 VLAN 的裝置分開，彼此看不到對方；要互通，流量非得往上送到路由器或防火牆繞一圈不可。而這一繞，正是我們動手腳的地方——在那裡擺上存取規則。
好的設計會採「預設全擋、逐條放行」（default deny）的態度：IoT 網段裡的裝置，預設誰都連不到住戶網段，只有明確需要的路徑——比如某顆感測器要回報給它的閘道器、閘道器要連原廠雲端——才一條一條打開。這麼一來，就算 IoT 網段裡某台裝置真被打下來，它能碰到的也只有同網段的鄰居，摸不到住戶的手機、電腦跟照片。這其實就是「零信任」講的「先不信任、逐次驗證」落在小型網路上的版本。要補一句：真正嚴謹的微分段（microsegmentation）會細到單一裝置對單一裝置，但 IoT 裝置多半裝不了代理程式，所以在住宅場景，用網路型的 VLAN 加防火牆規則來分段，是最務實的做法。
還有一個重點：門鎖與門禁的控制層，要比一般 IoT 更嚴。冷氣、燈泡塞在一般 IoT 網段就好，但門鎖的管理介面、監視主機，建議另外拉一個受更嚴格保護的管理網段，只有授權的管理端進得去，住戶網段完全碰不到。NIST 在 IoT 裝置的安全基線文件（8259 系列）裡談的也是這個精神：一台裝置能不能被識別、能不能更新、能不能管控存取，是它該具備的基本能力。
隔離不是「切開就沒事」：被低估的「找不到裝置」難題
這裡要講一件很多人切了 VLAN 才踩到的坑，也是判斷一個團隊到底懂不懂的分水嶺。你把 IoT 切出去之後，往往會發現手機上的 App 突然「找不到」那顆智慧插座了、跨螢幕的影音投放（把手機畫面丟到電視那種）也失靈了。不是設備壞掉，而是這些裝置的自動發現，幾乎都靠多播（multicast）——具體說是 mDNS，走 UDP 5353 送到 224.0.0.251（IPv6 則是 ff02::fb）這種連結本地位址。而連結本地的多播，天生就是不跨子網的：你一切 VLAN，它就到不了對面。
解法是在路由器或防火牆上開mDNS 反射（reflector，也叫多播中繼或 mDNS 閘道；Linux 上常用 Avahi 來做）：讓它把在一個 VLAN 上聽到的服務廣播，複製一份重新播到你允許的其他 VLAN。但光反射還不夠——反射只負責讓兩邊「看得到」，實際要通訊的那條單播（unicast）流量，還得在防火牆上補一條對應的放行規則才會通。同時建議打開交換器的 IGMP snooping，免得多播在網段裡漫天亂飛拖垮效能。更要提早想到的是：新一代的 Matter／Thread 走的是 IPv6，而多數現成的多播反射工具只支援 IPv4，這一塊若不先規劃，日後升級會卡住。這些細節不影響「要不要隔離」的結論，卻決定了隔離之後房客用起來到底順不順——安全跟好用之間的那條線，就是在這裡拿捏的。
最常見的幾個誤區，跟一份自保準則
先說幾個最常見、也最致命的誤會：
- 改了 Wi-Fi 密碼，就以為安全了。那只是換了進門的鑰匙，裝置本身的管理後台密碼常常還是出廠預設，而攻擊者走的正是後者。
- 把「訪客網路」當成完整隔離。訪客網路多半只做「用戶端隔離」，把連上來的裝置彼此隔開，但這不等於做了 VLAN 加存取規則的分段，兩者的防護等級差很多。
- 假設韌體會自己更新。很多裝置從出廠到報廢從沒更新過一次，甚至原廠早就停止支援了。
- 為了方便遠端看攝影機，把管理介面直接對外開埠（port forwarding）。這等於把後台掛在公網上任人敲，是被入侵的頭號原因之一。
對應的準則其實不複雜：預設全擋、最小放行；遠端管理一律走 VPN，不在路由器上對公網開埠；選品時把韌體支援年限、能否離線運作當成硬條件；智慧門鎖務必留機械或離線備援；並且定期盤點——手上到底有哪些裝置、各自韌體是什麼版本，心裡要有一張清單。
最後：規模決定做法，別過度、也別裸奔
要不要大動干戈，得看物件的規模。單間套房、只有三五個智慧裝置的房東，一台稍好、支援多 SSID 或訪客網段的路由器，把 IoT 跟住戶分開，通常就夠了，硬上一整套管理型交換器反而是過度工程。但如果是多戶分租、又共用了電子鎖、智慧電表、公共監視這些管理級設備，那就值得認真上管理型交換器，規劃 VLAN 與防火牆規則，把住戶、IoT、管理三層清楚切開。另外要提醒：只要設備會感測或攝錄到住戶的活動，就牽涉個人資料與隱私，設置與告知都得依相關規範和租賃約定來，態度上保守為宜。
「智慧租屋」在高雄——尤其對年輕租客和園區工程師——確實是愈來愈吃香的賣點，但智慧的前提永遠是安全，要是智慧門鎖反而成了駭客的後門，那就本末倒置了。廷皓科技在高雄替智慧化的分租物件規劃 IoT 獨立網段，把智慧門鎖、感測器、電表安全收編，跟住戶網路確實隔開，並提供月約代管。想做的若是「讓人安心的智慧租屋」，而不只是「裝了很多東西的租屋」，歡迎找我們一起把整體架構規劃好。
