Jamf 自動停用相機功能

最近像是大家說好似的,越來越多的企業或組織都在聊如何關閉照相功能。當用戶進入廠房或營區時,該如何讓他們在外面可以正常使用照相功能,但是一經過了刷卡上班的程序,或是進入到特定地域時,手機就會自動關閉照相功能。這篇文章就來聊聊如何在軍隊或是科技業裡利用 Jamf Pro API…

分享
Jamf 自動停用相機功能

最近像是大家說好似的,越來越多的企業或組織都在聊如何關閉照相功能。當用戶進入廠房或營區時,該如何讓他們在外面可以正常使用照相功能,但是一經過了刷卡上班的程序,或是進入到特定地域時,手機就會自動關閉照相功能。這篇文章就來聊聊如何在軍隊或是科技業裡利用 Jamf Pro API 針對人員的 iPhone 或 iPad 關閉照相功能 吧!

其實上面的這些問題全部都能實現,蘋果的 iOS、iPadOS 作業系統等也都內建了很強大的 MDM 框架,只要這些設備透過了第三方的的管理程式,如 Jamf Pro納管後,就可以開啟這些內建的管理功能。

目錄

這個系列有兩篇,主要是講如何滿足自動關閉相機的需求,主要會用 Jamf Pro API 及 Swift 語法完成相關內容。

自動啟動 MDM 框架 = 企業級蘋果設備

要進到正題前,其實要先說一下上文提到的 MDM 框架。事實上,不管是從法雅客購買的 iPhone、還是從 PCHome 取得的 iPad,每一台機器裡面都已經內建了 MDM 管理框架,只是從以上通路買到的設備,因為被蘋果視為個人設備,出廠時並不會啟動這個框架,直到使用者手動的將他自己的設備向第三方管理程式報到後,才會啟動這個管理框架。

換句話說,蘋果有另外一種方式,可以讓組織所採購的設備 ,就自動啟動管理框架。而框架如何被啟動的過程,也形成了其能管控的規模範圍。簡單來說,使用者手動向管理程式報到的設備,MDM 管理框架會進入到「登記模式」;而透過全自動啟用 MDM 框架的設備就會被入而「監管模式」。

登記模式 vs 監管模式

因為設備內被啟動管理框架的方式不同,IT 管理員能管理該設備的能力也就跟著不同。以登記模式來說,IT 管理員能從像是 Jamf 這樣的管理平台上對設備安裝 App、或者是移除先前安裝過的 App,但不能對該設備設定限制、也不可以隨意的刪除使用者 App,更不可能限制使用者只能拜訪哪些網站或哪些 App 了。

監管模式則很不一樣。啟用為監管模式的 iPhone 或 iPad 設備,會把裝置管理的最大權限交給 IT 管理員,讓他們可以在像是 Jamf 這樣的管理平台上對設備進行最高權限的管理,像是設備遺失時可以定位、可以在背景自動幫使用者安裝 App、主動限制使用者不能拜訪哪些網站、甚至把裝置上的 App Store 關閉,讓使用者再也不能隨意用自己的 Apple ID 下載 App。

BUT!能不能 關閉照相功能 ,完全是一個大例外。若照著剛才的邏輯,登記模式的設備可以允許 IT 管理員提供資源給用戶,但不能限制其設備的使用;而監管模式的設備不只可以被限制使用能力,管理員要提供資源給他們當然也絕對沒問題。不過再說一次,管理相機是個大例外,蘋果目前的規範是即便設備只進入到登記模式,不用特別進入到監管模式,IT 管理員仍然可以遠端的關閉人員相機的使用。

要不要進監管模式才能關閉照相功能,其實吵了很久

就目前寫這篇文章的時間點(2020 九月)來看,蘋果還沒有規定設備一定要進入到監管模式才能管理相機。也就是說,無論設備現在處於登記模式或是監管模式,IT 管理員都能對該設備的相機功能予以關閉。

近年來,蘋果一直希望往前一步,規範只有進入到監管模式的設備才能被管理員關閉照相功能,但受到全球企業/學校/軍隊用戶的反彈,目前這項政策還未見到實施之日。為什麼呢?以軍隊為例好了,很多人帶著自己的 iPhone 進到營區裡面使用,然而為了保防需求,軍隊裡的長官當然不希望軍人可以在營區內使用照相功能,因此多會要求設備管理平台在軍人進入營區後自動關閉相機。如果是這樣的話,為了要能夠滿足保防需求,軍人就再也不能自己花自己的錢買 iPhone,必須改由軍隊採購,並且自動啟動監管模式,這個對國家的預算編列實則不易,所以才會有不小的反對聲浪。

既然現在蘋果沒有強烈要求設備必須進到監管模式才能被管相機的話,代表 IT 管理員現在就能對使用者自己買的手機或是公司配發的手機,在進入到公司、廠房或營區時就自動 關閉照相功能 。

如何觸發相機關閉?

Jamf Pro 的裝置管理允許我們使用兩種方式自動管理設備,一種是透過 API、另一種是透過地理柵欄。這兩種加起來,幾乎可以處理大部分的自動化需求了。例如當使用者走入特定場域時,手上的 iPhone 就會自動觸發管理機制,進而關閉相機。或是利用 API 結合門禁系統,當使用者刷卡時就自動管理手機上的攝影功能等等。

使用地理柵欄的話,以 iBeacon 為比較常見的手段,這邊感覺可以另外再寫一篇文章了,所以暫時跳過。但如果是結合 API 的話,Jamf Pro 有提供大量的 API 可以與既有的系統整合在一起,可以參考 Jamf Pro API 文件

進入正題:如何導入 Jamf Pro API 跟門禁系統

因為我手上並沒有一個真正的門禁系統可以導入,但是做為概念應該是蠻夠用的。下面的影片裡,我在電腦裡面執行了一個模擬器,模擬為門禁系統。用戶需要先在門禁系統上輸入自己的姓名或工號,當作是上班打卡。所以也可以額外想像成,用戶需要用自己的識別卡感應門禁,做為上班打卡;或也可以想像是用戶對門禁完成人臉辨識,做為上班打卡等等。

不管是自己輸入姓名、員工編號、感應識別卡或人臉辨識,都必須是門禁資料庫裡面的唯一值(所以用姓名來當做例子不太洽當,畢竟一個公司裡面同名同姓的人可能不少)。而只要是唯一值,應該都可以對應到一組或多組設備管理碼,也就是該人員持有的設備。

如果是員工編號的話,應該會得出一個這樣的關係:

如果是感應識別卡的話,可能會得出這樣的關係:

手動綁定設備與人員之間的關係

上面的這兩個表格,最重要的部分是如何把這些關係對應起來。在 Jamf Pro 上面,管理員可以手動的把人員跟設備綁定起來;如果要全自動配對的話也可以,但前題是公司需要有目錄服務。

目錄服務是另外一個話題了,所以先單純的講手動配對吧。在 Jamf Pro 裡面找到該設備後,直接對設備的使用者進行編輯,就可以把人員指派給這個裝置:

透過智慧型群組達到自動化管控

Jamf Pro 裡面有一個蠻方便的功能,叫做智慧型群組,它應該是所有做自動化設備管理最關鍵的一項技術。概念很簡單,比起過去手動的一台台把設備加入群組裡面做管理,Jamf Pro 的智慧型群組可以用條件的方式找到設備。

舉個例子來說,用條件的方式我可以找到所有已經打卡上班的人員設備,並且對這些設備關閉相機。所以只要一有人打卡上班,就會自動掉入到這個群組裡,並且自動被關閉相機,中間不需要任何的人為介入。

為了要實現這項功能,我們得在 Jamf Pro 上標記哪一些裝置「正在上班中,相機必須被關閉」,因此就會需要結合到第二個 Jamf Pro 裡很好用的功能,叫做延伸式屬性。

透過延伸式屬性(Extension Attribute)增加設備管理能力

當蘋果設備一被 MDM 管理後,就會提供設備的硬體訊息給 MDM 平台。以 Jamf Pro 為例,除了原本會從設備取得的基本訊息外,還能自己增加欄位(如紅框所示),並且從 Excel、AD 目錄伺服器、API 或手動等方式餵入資訊。

智慧型群組+延伸式屬性客製化自動管控

經過上面兩點,我們就能在 Jamf Pro 裡面增加一個屬性叫做「需關閉相機」的欄位,並且製作一個智慧型群組,找到所有「需關閉相機」欄位值為「是」的設備。

接著,再利用 Jamf Pro 提供的 API 跟門禁系統整合,只要人員一打卡上班,就依據他的卡號,找到他在公司裡面的工號,進而透過 Jamf Pro 找到他的裝置管理號碼,然後把那台裝置的「需關閉相機」欄位切換成「是」,如此一來這個設備就會自動掉入智慧型群組。

最後,我們只需要把關閉相機的設定套用到「需關閉相機的智慧型群組」就完成了。

Read more

Managed Preferences 到底贏不贏得過本機設定?自己寫工具測給自己看

Managed Preferences 到底贏不贏得過本機設定?自己寫工具測給自己看

在管理一批用 MDM 集中控管的 Mac 時,常常會遇到一個問題:某個 preference key,使用者自己用 defaults write 改過一次,管理員可能又用 sudo defaults write 在系統層級動過一次,最後 MDM 又把同一個 key 標成 Managed(強制)。這時候系統實際生效的到底是哪一個值? Apple 官方文件對 CFPreferencesAppValueIsForced 這支 API 的說明相當簡略,只告訴你這個 API 可以拿來判斷某個 key 是不是被強制,卻沒有把整個 preference 搜尋順序裡各層級的先後關係講清楚。網路上能找到的資訊也大多是憑印象轉述,沒有人真的擺出證據。 與其對著文件猜,不如自己寫一支工具,實際測給自己看。以下這篇的測試環境是 macOS Tahoe 26.6.

By Glee Tsai
Apple 生態系的真實威脅—我們都可能是目標

Apple 生態系的真實威脅—我們都可能是目標

從一場分享開始的警醒 前陣子在 Jamf Nation Live Taipei 分享了 2024-2025 年 Apple 裝置威脅報告,深入探討了全球 Apple 生態系正面臨的資訊安全威脅。 許多人對 Apple 產品有一種根深蒂固的信心—拿著 Mac 或 iPhone,就像拿到了數位世界的「免死金牌」。說實話,Apple 在軟硬體整合上的安全設計確實領先業界,這不是誇大其詞。但也正因為這份信心,我開始想更深入地了解真實情況。 從 Jamf Security 360 報告開始,我觀察了全球情報機構(如 Citizen Lab、Google TAG、Kaspersky)揭露的真實案例。那時我才意識到一個有點殘酷的事實,也正好對應了同事最常對我說的那句話:Apple 設備並非堅不可摧,使用者自身往往才是最大的弱點。 為什麼 Apple

By Glee Tsai

從 Jamf Pro 自定義註冊畫面帶使用者資訊至 Jamf Connect 失敗的處理方式

Jamf Pro 在設定裡面的 Enrollment Customization,本來可以設定在使用者完成設備註冊的當下,同步把 SAML 裡的資訊帶給後面的 Jamf Connect Login,這樣就可以減少一步使用者還需要登入的步驟。但在撰文的當下,Jamf Pro 11.1 仍在這個功能上有問題,在跟 Jamf Support Team 了解後,大概能用一種 Workaround 來解決,只是要特別留意以下事情: 1. 在 Jamf Pro 裡的 Enrollment Customization 不要再打勾 Enable Jamf Pro to pass user information to Jamf Connect 了(因為勾了也沒有用) 2. 確保

By Glee Tsai

在 Apple 零接觸部署下僅允許某個群組啟動設備

在 Jamf Pro 有整合 Single Sign On 的情況下,可以前往 Settings > Enrollment Customization 設定僅允許一個群組中的成員啟用設備。如果這個成員沒有在這個群組裡面的話,就不能夠開箱設備。如果以 Entra ID 為例,需要把 Object ID 填在下方的欄位即可。 對照到我在 Entra ID 上的群組設置: 至於如果不是 Entra ID,而是其它的 SSO Provider 的話,最好可以用 SAML Tracer 這一套 Google Chrome 外掛去看一下自己的 SAML 文件是如何表達群組的,例如下圖能看到這個使用者屬於以下五個群組。 接著有另外一個很重要的事情要提醒,如果你要阻擋註冊的成員,可以登入到 Jamf Pro

By Glee Tsai