2021.3.1

VPP(Volume Purchase Program)・アプリ一括購入とは何か

VPPとは、企業がアプリやブックを一括購入するプログラム(Appleとの契約)のことです。

VPPによって、企業はアプリ購入費を各従業員に立て替えさせたり、1つのAppleIDを使ってアプリを共有利用するグレーな運用をしなくてもよくなります。法人向けパッケージソフトのように、人数分のライセンスをまとめて購入する仕組みをAppleはちゃんと用意してくれているのですね。


(VPPは一括購入専用の法人用サービス。利用には専用のAppleIDを用意してAppleに申請する必要があった)

昔は上図のようなVPP専用の画面がありましたが、今はABMに一括購入の機能が統合されています(参考 : ABMとは何か)。本稿ではそんな歴史にも軽く触れつつ、アプリ一括購入についてご紹介します。

 

VPPとアプリ一括購入の歴史

まず簡単にVPP(Volume Purchase Program)の歴史を見ておきましょう。

2011年 VPP発表
2012年 VPPが日本でも利用可能になる
2014年 端末の一括購入を支援するDEP(Device Enrollment Program)の登場。「一括」系を支援するプログラムとして VPP と DEP はまとめて Apple Deployment Programs (ADP) と呼ばれるようになる
2018年 ABM(Apple Business Manager登場。一括購入はVPPからABMへの移行が促される
2019年 VPP廃止

2012年の「日本でも利用可能」というのが面白い表現ですね。これはAppStoreが国別に用意されていることに関係していて、AppStoreと連携する一括購入の仕組みも国ごとに異なるからです。このことは後述の一括購入したアプリの配布方法で重要なポイントになりますので、覚えておいて下さい。


(2011年のVPP発表当初は米国のみ。2012年に日本を含む米国以外の9ヶ国に対応した)

振り返ってみると、2008年に登場したiOSが、早くも2009年にMDM対応し、2011年にVPPで一括購入の仕組みが用意されたということですので、Appleの法人向け戦略にスピード感があったことがよく分かります。

その後、2019年にVPPは廃止され専用の管理画面もログインできなくなり、AppleもオフィシャルにはVPPという言葉をほぼ使わなくなりました。


(VPPにはサインインできないようになり、ABMへの誘導リンクがあるのみ)

ですが、今でも関係者の間ではVPPは一括購入を表す言葉として残っています。VPP購入と表現する人もいますし、一部のMDMサービスでは管理画面上でまだVPPという言葉を使っていたりします。実は、Appleの公式ドキュメント(利用規約やマニュアル)の一部でもVPPという言葉がまだ残っています。

紆余曲折してきた結果、全体としてまだ余り統制が取れていないのが分かりますね。ただ余り気にする必要はなく、こんな歴史があったということだけ念頭に置いて「VPP = 一括購入」とザックリ捉えておけば問題はないでしょう。

さて、歴史はこれぐらいにして、以下アプリ一括購入の詳細を解説していきます。

 

一括購入できるもの

一括購入できるアプリは大きく分けると2種類あります。

  • AppStore向けアプリ (公開アプリ)
  • カスタムApp (非公開アプリ。業務用アプリ)

AppStoreアプリというと普通は前者だけが思い浮かびますが、実はAppStore上には特定の企業にしか見えない非公開の業務アプリが多数存在します。どういうことか。


(AppStoreアプリを申請するADPの画面。アプリごとに配信方法を決める。通常は公開だが非公開も選択可)

VPPの登場した2011年から「非公開」のAppStore申請はできるようになってました。ADEPのInHouse配布があったので余り知られていなかっただけです。AppStoreの非公開アプリを当初はカスタムB2Bと呼んでいましたが、今はカスタムAppと呼びます。

カスタムAppは、特定の顧客企業向け、あるいは自社の業務専用アプリをAppStoreインフラを使って非公開で配布する方法で、2021年現在ADEPによるInHouse配信に代えて使用することが推奨されています。(参考 : ADEPはもう取得することができないと諦めたほうが良い理由)

少し横道にそれましたが、カスタムAppも公開アプリと同じAppStoreインフラを使いますので、公開アプリと同様に一括購入の対象となります。とにかくAppStoreのインフラに乗っかれば一括購入対象になると捉えると良いでしょう。

加えて、(アプリではありませんが)AppleBooksで公開されているブックも一括購入対象となります。業務に使える電子書籍がもしあれば活用できるでしょう。ということで、

  • iOS向けアプリ
  • iPadOS向けアプリ
  • macOS向けアプリ
  • tvOS向けアプリ
  • ブック

これらが一括購入できるものになります。アプリの有償・無償関係ありません。また公開・非公開、どちらのアプリも対象になります。(非公開ブックは存在しない)

 

一括購入での決済手段

決済手段は以下の2種類が用意されています。

  • クレジットカード
  • ストアクレジット

前者は想像の通りですね。個人向けAppStoreと変わりません。一括購入では法人用のコーポレートカードをABMに登録します。設定画面が用意されており、ABMで一括購入すると法人カードで決済されます。


(請求先情報に住所と法人カード情報を登録する。一度登録すると一括購入時にカード決済してくれる)

もう一つのストアクレジットは馴染みがない方が多いかも知れません。一言で言うと、法人向けプリペイドクーポンです。個人がコンビニなどで購入できる、1円単位で金額指定可能なバリアブルiTunesカードの法人版です。

Appleと日頃から取引がある企業はAppleから提供を受けている専用サイト(MyAccess)から、Apple製品の正規販売代理店と付き合いのある企業は当該代理店に、「ABMでアプリを一括購入するので10万円分のクレジットが欲しい」ってな感じで依頼して下さい。然るべき対応をしてくれる筈です。

普段の取引と同様に、見積書→発注書→請求書→入金→領収書の流れでクーポンを入手、ABMに登録するとクーポンの金額分を一括購入の原資にあてることが可能になります。


(ストアクレジットを販売店に発注し請求書払いすればカードが使えなくても一括購入ができる)

以上2種類の決済手段のみとなります。法人カードの決済上限額が問題になる場合もあるでしょうから、ある程度の企業規模ではクレジットカードとストアクレジットを併用するのが良いでしょう。

 

一括購入したアプリを配布する方法

一括購入したアプリは配布してナンボですね。500個購入したら500人(あるいは500台)に届けなければなりません。ここでは一括購入したアプリの配布方法について見ておきます。

配布方法は以下の2通りが用意されています。

配布方法 使うシーン
管理対象ライセンス MDMを使って組織所有の管理端末に配布する
引き換えコード 引き換えコードを使って個人所有の非管理端末に配布する

一括購入する際に、2種類の配布方法からいずれかを選択して購入します。


(配布方法を選んでいる様子。AppStore公開アプリの無料アプリは、管理対象ライセンスしか選べない)

購入した後に配布方法を変えることはできません。一括購入をする前に配布方法を決定しておくことが重要です。どちらを選ぶべきか判断材料を以下にまとめました。

管理対象ライセンス 配布先 会社配布のMDMチェックイン済み端末
メリット インストールさせ易い (設定次第で強制インストールも可)
退職者に割り当てたライセンス回収が可能
MDMで集約管理ができる
デメリット MDMにチェックインした端末にしか使えない
コード配布 配布先 個人所有の端末
メリット MDMを必要としない
デメリット インストールを強制・管理できない
退職者に割り当てたライセンス回収ができない
ABMとAppleIDの国が異なると使えない

以下、それぞれ深堀りして解説します。

ライセンス配布

iOS端末を会社で調達し従業員に配布していたり、施設に配備するなどしていて、MDMで集中管理している場合はライセンス配布を選ぶべきです。ABMとMDMを連携させると一括購入したアプリのライセンスをMDMに転送でき、MDM上でアプリと端末を併せて管理できるからです。


(最も理想的な配布・配備が可能になる)

特に従業員が辞めた時や端末の利用者が変わった時にこのメリットが活きてきます。MDMで端末との紐付けを設定するだけでどの端末にどのアプリをインストールするか制御できますので、ライセンスの回収や付与先変更が容易なのですね。

デメリットはMDMの管理対象端末でしか使えないことです。もし業務用に使わせたい一括購入アプリを従業員の個人所有端末に配布したいという場合は、以下に解説する引き換えコードを選ぶ必要があります。

引き換えコード

会社として業務用端末を調達しておらず、従業員の個人所有端末を業務に使わせて貰うような場合に使用します。引き換えコードの方式で購入すると、一括購入した数だけ各従業員が AppStore で使えるコードを発行して貰えます。


(一括購入後にコード一覧のExcelファイルをダウンロードできる)

ダウンロードからコード一覧が書かれたExcelファイルを入手できます。


(3つ一括購入した時のExcelファイル)

重複しないように従業員1人に1コードずつ配布します。メールで個別に送信しても良いでしょうし、ログイン機能のある社内ポータルサイトがあればマイページ等で個別に表示して提供するのもありでしょう。

従業員は、コードを入手したら個人端末上でAppStoreアプリを起動し、「コードを使う」画面から使用します。


(AppStoreアプリのゲームタブやAppタブの最下部にある)

コードを入力するとライセンスが個人のAppleIDにひも付いてアプリがインストールされるという仕組みですね。一括購入時に決済は完了しているので従業員側での支払いは不要です。

Excelファイルには各コードに対応するURLも提供されています。これを従業員に提供し、iOSの Mobile Safari からURLを踏んで貰うという配布も可能です。


(URLを踏むとAppStoreアプリの起動とコード入力までしてくれる。このあとアプリは自動インストールされる)

以上が引き換えコードの詳細です。MDMが不要なので一見便利なのですが、注意点が2つあります。

1つ目はライセンスが個人のAppleIDに紐づくという点。当該従業員が退職した後に、アプリを強制アンインストールしたり、アプリの継続利用や再インストールを禁止することはできません。カスタムAppの企業内専用アプリを引き換えコードで一括購入する場合は、アプリ内に独自の認証機構がないと情報漏えいに繋がる可能性があるので特に気をつけて下さい。

2つ目は国。ABMを使用する企業の国と引き換えコードを使用するAppleIDの国は一致している必要があることにも注意しましょう。

例えば、ABMを使う日本の企業が引き換えコードで一括購入したアプリを、米国駐在員に使ってもらおうとするケース。もし駐在員が個人端末を米国AppStoreのAppleIDメインで使っている場合はインストールできないということです。

ABMとAppleIDの国が異なると、コードの適用時に以下のような画面がでます。


(日本でABMを使う企業の引き換えコードを米国のAppleIDで使っている端末に適用しようとして失敗する例)

冒頭で言及しましたが、AppStoreと一括購入の仕組みが国ごとに異なっていることは、こんなところに影響してくるのですね。事業を国際展開している企業がコード引き換えを使う場合は注意が必要です。

 

以上、VPP(Volume Purchase Program)とアプリ一括購入について解説してきました。長くなった為、実際に一括購入する手順は紹介できませんでしたが、これはまた別の記事で紹介したいと思います。

2021.2.22

Apple Push Certificates Portal で使うべき AppleID のガイドライン

エンタープライズiOSでは複数のAppleIDが必要になります。主なものを以下に挙げてみました。

No. AppleIDが必要なサービス・契約 必要な時
(1) Apple Push Certificates Portal MDMを使う場合
(2) Apple Business Manager (ABM) 業務用アプリの一括購入やDEP端末を使用する場合
(3) Apple Developer Program (ADP) 業務用アプリを自社開発(外注含む)して使用する場合
(4) Apple Developer Enterprise Program (ADEP) iDEP,ADEPを取得していてInHouseアプリを運用している場合
(未取得企業なら2021年現在は考慮不要。こちら参照)

大半の企業では (1), (2) の2つのみが必要で、自社専用アプリを開発する場合は (3) を加えた最大3つのAppleIDを管理・運用することになります。

悩ましいのは、それぞれで使用するAppleIDがどうあるべきかのガイドラインを Apple が示してくれていないことです。

そこで本稿では、Apple Push Certificates Portal で使うAppleIDについて指針を示したいと思います。(Apple Push Certificates Portal についてはMDMの導入から利用開始まで(1) 〜PUSH証明書の取得〜を参照のこと)

 

Apple Push Certificates Portal に個人AppleIDを使うと運用で詰む

ときどきある間違いが、MDM導入初期の担当者個人の AppleID を使ってしまうことです。「AppleID が必要なのね、なるほどなるほど、既に持ってるよ」的なノリで、

  • 担当者のプライベートな私用のAppleID
  • 会社供与の個人用メールアドレスに紐づくAppleID

を使用してしまうと、将来、運用上のトラブルを発生させる可能性があります。なぜでしょうか?


(PUSH証明書取得のためにしか使わない Apple Push Certificates Portal)

Apple Push Certificates Portal で取得するPUSH証明書は、申請時のAppleIDとユニークに紐づきます。そのため、1年後の更新時は、取得時と全く同じAppleIDでサインインする必要があり、他のAppleIDを使って更新することはできません


(サインイン後の画面は、そのAppleIDで取得したPUSH通知書が並ぶだけ。これ以外の機能は一切ない)

例えば、担当者Aさんの個人AppleIDで取得したPUSH証明書は、翌年またAさんが更新しなければなりません。もし翌年、Aさんが退職していたらどうなるでしょうか?…PUSH証明書の更新が極めて困難になるということは想像に難くありません。

PUSH証明書を更新できなければ、MDMの全機能が使用不可となります。

別のAppleIDでPUSH証明書を取得し直すこともできますが、残念ながらその場合は「更新」ではなく「新規」の扱いとなります。これは、全デバイス再登録を含むMDM初期設定作業のやり直しを意味しています。目も当てられない事態ですね。


(同じドメインの別AppleIDでサインインした様子。同じ会社ドメインのAppleIDなのに何も表示されてない…)

ですから、個人に紐付いたAppleIDは使うべきではありません。

Apple Push Certificates Portal は、AppleIDがどこの企業のものかを全く気にしないことに留意しましょう。提出されたCSRがファイルとして適切なら、サインインしてきたAppleIDにPUSH証明書が発行されます。証明書をMDMサービスに紐付けたが最後、そのAppleIDで更新し続けなければならなくなります。

 

PUSH証明書は企業内共用AppleIDで取得する

前節の繰り返しですが個人のAppleIDは使うべきではありません。その代わりに、

  • info@example.com のような共用メールアドレス
  • devgroup@example.com のようなメーリングリストやエイリアス

で作成した AppleID を使用すべきでしょう。もし可能なら push@example.com や apcp@example.com など Apple Push Certificates Portal に使うことが分かるようにしておくと、いざPUSH証明書を更新する時に迷わずに済むのでお勧めです。(1年後なのでだいたい忘れているものです)

サインインパスワードは自社のセキュリティポリシーに従って共有管理して下さい。(弊社では法人向けパスワード管理サービスの 1Password Teams を推奨しています)

また、AppleIDでは、2ファクタ認証のため電話番号も必要になります。


(2021年現在、全てのAppleIDで2ファクタ認証が必須)

確認コードを受け取る電話番号もメールアドレスと同様、プライベート用か会社供与のものか関係なく個人に紐付いた番号は避けるべきです。情報システム部門として共用の電話番号を確保し、それを紐付けるのが良いでしょう。

 

ABM の Managed AppleID を使うこともできる

余りないケースですが、MDM導入前からABMが利用可能な場合は Managed AppleID を使うのもお勧めです。(参考 : ABM(Apple Business Manager)とは何か)

Managed AppleIDは、通常の AppleID と違って登録時の煩わしい各種入力が不要で、ABMの画面から簡単に作ることができます。


(ABMから作成する Managed AppleID は誕生日等の入力項目がなく必要最低限でok)

パスワードや電話番号のリセットも容易に行えますし、AppStoreアプリやiTunesのコンテンツが元々購入できない制限付きAppleIDですので、管理側として都合が良いです。


(Managed AppleIDはABM上から各種リセットが行える)

例えば、ABMで push@example.com といった Managed AppleID を作っておき、MDMサービスを契約後、Apple Push Certificates Manager にサインインしてPUSH証明書を取得、MDMに証明書を登録し、ABMとMDMも連携させる。こうすれば、ABMにMDM関連が集約できて分かり易いですね。

iOS端末の業務導入が初めて…という場合は、MDMサービスの選定を行うと同時に、ABMを利用申請しておくのも良いでしょう。iOS端末の業務活用を推し進めるとどうせABMは使うことになるからです。

  

以上、Apple Push Certificates Portal で使用する AppleID について紹介しました。まとめると、Apple Push Certificates Portal に使う AppleID ガイドラインは以下となります。

  • 公私関わらず個人に紐づくAppleIDの使用は避ける
  • info@〜等の社内共用のAppleIDを使う
  • 可能であればABMのManaged AppleIDを使う

適切な AppleID を使用して将来のMDMトラブルを避けましょう。

2021.2.15

MDMの導入から利用開始まで(1) 〜PUSH証明書の取得〜

(最終更新日 : 2021/2/22)

MDMとは何かの投稿やMDMの導入で意識しておきたい社内ネットワーク設定の投稿で紹介した通り、MDMが機能するためには、PUSH通知が必要不可欠なのでした。


(APNs = Apple Push Notification service)

APNsは、Appleがお金と人と時間をかけて管理・運用している通知システムです。誰もが自由に上図①のPUSH通知要求を出せるわけではありません。Appleが発行する「許可証のようなもの」を持っているサーバだけが送ることができる仕組みになっています。

その「許可証のようなもの」を、PUSH証明書といいます。PUSH証明書は、MDMサービスを使う企業単位でAppleから発行して貰い、MDMサーバに設置する必要があります。手順は以下の通り。

  1. MDMサービスからCSRを取得する
  2. Apple Push Certificates Portal (APCP) でCSRを使って申請し、証明書を取得する
  3. 取得した証明書をMDMサービスに登録する

MDM導入企業全てが、MDMを使い始める前(MDMサービスを契約した直後)に例外なく行う必要があります。本稿ではその手順を画面キャプチャつきで詳しく紹介します。

 

1. MDMサービスからCSRを取得する

PUSH通知証明書は、導入企業がいきなりAppleに申請できるものではありません。

まず最初に「APNs利用申請書」に相当するものをMDMベンダーに作ってもらいます。これをCSR(Certificate Signing Request)と言います。CSRは、MDMベンダー視点で書くと、

  • ウチの顧客の□□□様が
  • ウチのMDMサービス◯◯◯を使ってPUSH通知要求を送れるようにしたいです

というニュアンスのAppleへの申請書と捉えると良いでしょう。

CSRは単なるファイルであり、MDMサービスに契約するとその管理画面からダウンロードできるようになっています。MDMサービス契約直後は、MDMで何ができるのかとか、デバイスやアプリや設定の登録とか、色々気になるところですが、まずは真っ先にCSRをダウンロードしましょう。


(BizMobileでのPUSH証明書用のCSRダウンロード画面。他サービスでもほぼ同様)

なおPUSH証明書に関連する手続きはWebブラウザで完結しますので、Macである必要はありません。WindowsPCでも大丈夫です。ただWindowsPCを使うにしても、IEは使わないほうがいいでしょう。

オンプレミス型のMDMシステムを導入する場合は、手順が異なりますのでメーカに問い合わせて下さい。

 

2. Apple Push Certificates Portal でCSRを使って申請し証明書を取得する

次に1.で取得したCSRファイルを Apple Push Certificates Portal (APCP) というサイトにアップロードして申請します。


(APCP = Apple Push Certificates Portal は、PUSH証明書を取得するためだけにAppleが用意しているサイト)

PUSH証明書の申請は、ADEPやABMの申請とは異なり、Apple側の人手を介した審査プロセスはありません。サイト上で自動で処理され即時発行されます。手順を見てみましょう。

(1) まず、 Apple Push Certificates Portal にアクセスします。サインインが求められます。

(2) AppleIDでサインインします。ここで使用するAppleIDは個人のものを使うべきではなく、企業用の特定人物用ではないメールアドレスで別途取得したAppleIDにして下さい。(ここで使うべき AppleID については Apple Push Certificates Portal で使うべき AppleID のガイドライン をご覧下さい)

(3) サインインできれば [Create a Certificate] ボタンをクリックします。

(4) 利用規約に同意します。「I have read 〜」のチェックボックスをONにして [Accept] をクリックします。念の為に Printable Version のリンクからPDF版をダウンロードしておくと良いでしょう。


(右下の国旗アイコンから言語変更ができそうに見えるが残念ながらできない)

(5) CSRのアップロードを促されますので 1. で取得したCSRを指定します。必須ではありませんが、Notesに何か分かり易いメモ書きをします。入力が終われば [Upload] をクリックします。


(Noteは、長さは200文字・日本語不可・英数字のみ・記号不可という制約があり自由度が極めて低い)

(6) 即時、PUSH証明書が作成されますので [Download] をクリックします


(CSRがおかしい場合はここでエラーがでる)

以上でPUSH証明書が入手できました。

ファイル名は

MDM_[MDMベンダー名]_Certificate.pem

となっている筈ですので間違いがないか確認しましょう。

 

3. 取得した証明書をMDMサービスに登録する

最後に、入手したPUSH証明書(.pemファイル)をMDMサービス側に登録します。

どんなMDMサービスでも、 1. のCSRダウンロードと同じ画面で .pem ファイルを登録できるようになっています。指示通りに登録しましょう。


(BizMobileでの証明書登録画面。.pemファイルが正しいかどうかはMDMサービス側が検証してくれる)

ところで、PUSH証明書ファイルは有効期限が1年と決まっており、以後1年ごとにPUSH証明書の更新作業が必要になります。更新を忘れるとMDMからAPNsへ通知要求が送れなくなりますので注意して下さい。


(MDMのトライアングルが分断されてMDMが機能しなくなる。最も避けなければならない事態)

通知要求が出せないということは、MDMが機能しなくなるということです。端末に命令も飛ばせませんし、アプリのインストールも設定の流し込みもできず、端末の情報収集も止まってしまいます。

従って、MDMのPUSH証明書更新はMDMの運用で一番気をつけるべきことです。通常はMDMサービス側が期限切れ1ヶ月前などに警告メールを飛ばしてくれますが、ご自身でもリマインダーを登録しておきましょう。MDMの導入・運用支援をするSIer様におかれては、更新忘れというポカミスでお客様の業務を止めないよう厳重に注意して下さい。

 

ということで、本稿ではMDM導入の最初で必要となるPUSH証明書の取得について解説しました。MDMに関しては以下のような記事もありますので併せてご覧下さい。

 

2021.2.1

MDMの導入で意識しておきたい社内ネットワーク設定

以前に書いたMDMとは何か 〜今さら聞けないMDMの基礎〜の投稿で、MDMがどのように動作するかを簡単にご紹介しました。


(APNsが重要な役割を担う。APNsは Apple Push Notification service の略)

この図の通り、

  1. MDM上の操作でAPNsにPUSH通知要求が送られ
  2. APNsからiOS端末にMDM専用のPUSH通知が飛び
  3. iOS端末はMDMから命令を取得して実行結果を返す

ということでした。本稿では、この一連の流れにおけるTCP/IP通信について深堀りし、企業がMDMを導入するに際して気をつけたいネットワーク設定について解説します。

 

MDM+APNs+iOSのTCP/IP通信トライアングル

まず最初に、MDMを取り巻くTCP/IP通信の全体像を示します。


(矢印の方向は接続を確立しに行く方向。APNs〜iOS端末間の矢印が直感とは逆向きであることに注意)

NO 接続・通信 使用ポート 意識する必要性 説明
1 MDM 〜 APNs TCP/443
(TCP/2197)
オンプレ型のMDM MDM用のPUSH通知要求がAPNsに送られる
2 APNs 〜 iOS端末 TCP/5223 全てのMDM APNsからiOSにMDMの処理を開始せよと通知が送られる
3 iOS端末 〜 MDM TCP/443 全てのMDM iOS端末によるMDM命令の取得と実施結果の送信

以下それぞれの接続と通信内容について解説していきます。

 

1. MDM〜APNs間の通信

MDMが端末に命令を送ろうとするとき、MDMはまずAPNsに対して「iOS端末にPUSHを送ってくれ」と依頼します。(このときiOS端末を識別するプッシュトークンと呼ばれる情報を一緒に送りますが詳細は割愛します)


(iOS端末にMDMが「直接」命令を送りつけるのではない)

この際、MDMからAPNsへの通知要求に使われるのがTCP/443です。図で括弧付きで書いているTCP/2197は、TCP/443を使うのが難しい場合に代替で使用するポートです。Apple公式ドキュメント Communicating with APNs には以下の記載があります。

You can alternatively use port 2197 when communicating with APNs. 
You might do this, for example, to allow APNs traffic through your firewall
but to block other HTTPS traffic.

なお、従来はこの通知要求にTCP/2195(とTCP/2196)を使用していましたが、現在は非推奨となっており2021年3月からはサポート外となります。(参考 : Apple 製のデバイスで Apple プッシュ通知が届かない場合の「関連情報」の欄)

MDMからAPNsへの通知要求に関連するTCPポートを改めてまとめると

TCPポート番号 説明
TCP/443 通知要求で原則的に使用する
TCP/2197 TCP/443が使用できない時に使う
TCP/2195
TCP/2196
現在使用は推奨されていない
(TCP/2196は通知用というより、通知に失敗したiOS端末情報をAPNsから取得する為の通信用ポート)

となります。基本的にMDMからAPNsへの通知要求はTCP/443という理解で問題ないでしょう。

既にお気づきと思いますが、導入しようとするMDMサービスがSaaS型のものであればこれらのTCPポート情報を気にする必要はありません。MDM〜APNs間の通信は、MDMサービスを開発・保守・運用するMDMベンダーが気にすべきポイントだからです。

ただしかし上図のように、社内設置するオンプレミス型MDMを導入する場合は、イントラネットからAPNsに向けてTCP/443を許可してあげる必要があります。もしTCP/443を許可できないならTCP/2197を許可する必要がありますね。詳しくは導入するMDMのベンダー担当者に問い合わせて下さい。

なおAPNsのIP範囲は 17.0.0.0/8 です。TCP/443またはTCP/2197の通信を外向きに許可する宛先情報として指定しておきましょう。

 

2. APNs〜iOS端末間の通信

MDMを導入したのに正しく動作しない…という時は、多くの場合、APNsからiOS端末に通知が届いていないことが原因です。

APNsはMDMからのPUSH通知要求を受けてiOS端末にPUSH通知を送るのでした。では、そのPUSH通知はネットワーク的にはどのようにiOS端末に届くのでしょうか。

APNsからiOS端末に接続要求をして接続できてから送る?それとも、iOS端末がAPNsをポーリング(自分宛の通知がないかどうかをひたすら問い合わせ続けること)する?

実は起動直後のiOSは、APNsに対しTCP/5223で永続的な接続を確立しにいきます。MDMから通知要求を受け取ったAPNsは、そのピアにPUSH通知用データを送り、iOS端末側には即座に伝わります。前述したような、APNsからいちいちiOS端末に接続しにいったり、iOSがAPNsにポーリングするのでは、安定した通知にはならないですね。ですから、TCP/5223はPUSH通知の根幹であり、MDMの要(かなめ)なのです。

閉域網を使っていたりVPNを経由する環境では、多くの場合、社内・グループ内のネットワーク設定の調整が必要になるでしょう。ネットワーク 17.0.0.0/8 にあるAPNsに接続確立できるよう 外向き TCP/5223 を許可するようにして下さい。

万が一 /8 という広範囲での許可が難しい場合、Apple の公式ドキュメントを参考に以下のレンジを全て指定すると良いでしょう。(参考 : Apple 製のデバイスで Apple プッシュ通知が届かない場合)

  • 17.249.0.0/16
  • 17.252.0.0/16
  • 17.57.144.0/22
  • 17.188.128.0/18
  • 17.188.20.0/23

なお Apple公式ドキュメントによると、TCP/5223を通せない場合にTCP/443をフォールバックとして使うことになっていますが、iOS端末とAPNsの間に通信を一度復号して中身を監視するようなプロキシがあると巧く動作しません。

またこのフォールバック用 TCP/443 が使われるのは、セルラーモデル端末でモバイル通信をOFFにしている時ということが知られています。「TCP/5223 がダメなら自動で TCP/443 を使ってくれる、だからTCP/443さえ許可すれば良い…」という意味ではありませんので注意して下さい。

結局のところMDMの導入では、イントラネットからAPNsに対して外向きTCP/5223を通すのが無難ということになります。

 

3. iOS端末〜MDM間のネットワーク疎通

さて、APNsからPUSH通知を受け取ったiOS端末では、mdmdというプロセスが動き始めます。


(Apple Configurator2 のコンソール画面で mdmd の動作を確認できる)

mdmdは、命令をMDMに問い合わせたり、命令実行の結果をMDMに伝えたり、更に次の命令を受け取ったりします。この通信に使用されるのが、iOS端末からMDMに対するTCP/443です。


(命令の取得と直前の命令実行結果の送出を1リクエスト内で同時に行う)

もし社内ネットワークから外向きTCP/443を制限している場合、MDMサービスのIPに対する外向きTCP/443は最低でも許可する必要があります。またオンプレ型MDMの場合は、MDMサーバにTCP/443で接続できるようローカルネットワークのルータやスイッチ、VLANの設定等を確認する必要があります。

 

以上、MDMの導入で気をつけておきたいネットワーク設定について紹介しました。最後に参考となる Apple 公式ドキュメントへのリンクを一覧しておきます。

ちなみにネット上にある情報の一部には、本稿で説明したMDMに関係する全ポート(TCP/443,2195,2196,2197,5223)を許可するよう記述しているものもあります。が、やみくもに許可するのは企業内ネットワークのポリシーとして不適切ですので、本稿を参考に必要最低限の設定にして下さい。

2020.11.23

iOSの監視モード(Supervised Mode)とは何か

iOSには大きく2つの動作モードがあります。1つは普段から使用している通常モード、もう1つは各種制限をかけられる監視モード(Supervised Mode)です。


(iOSDC Japan 2020 での講演スライドより)

監視モードとは、iOSの標準機能の多くに制限をかけたり特別な振る舞いをさせることができる特別なモードのこと。企業でのiOS利用を想定してAppleが用意してくれているもので、Apple Confirugrator2 を使うなど複数の方法で有効にすることができます。

監視モードでは、標準アプリを非表示にしたり、逆にアプリを削除できなくしたり、管理部門にとっては非常に都合がいいことが多いため、昨今では企業が調達して配布・配備するiOS端末は、監視モードにするのが当たり前になってきています。


(提案力UPに繋がるので、SIerやアプリ開発会社も監視モードを理解していることが推奨される)

監視モードについて知ってるか知らないかは、エンドユーザ企業では運用のし易さ、アプリ開発会社では提案の優劣に影響します。そこで本稿では、監視モードで何ができるようになるのか?について以下3点を解説します。

本稿を読むことで、監視モードとは何かをイメージして頂けるようになると思います。(監視モードにする方法は iOSを監視モードにする方法 〜保存版 : Apple Configurator2編〜 をご覧下さい)

 

(A) サイレントインストールが行えるようになる (インストールの強化)

監視モードでは、アプリや構成プロファイルのインストール時の振る舞いが少し変わります。具体的には、

  • (1) MDMを使ったアプリのインストール
  • (2) Apple Configuartor2 を使った構成プロファイルのインストール

この2つのインストールの際に、デバイス側の確認が不要となりインストールを強制できるようになります。順に見ていきましょう。

(1) MDMでのアプリインストール

通常、MDMからアプリがインストールされる時には以下のようなダイアログが表示されます。


(デバイス利用者がインストールに「同意」する必要がある。誤ってキャンセルを押してしまう可能性も…)

上図ではMDMからGmailアプリがインストールされようとしていますね。ただ、端末利用者が「キャンセル」を押せばアプリは当然インストールされません。一度キャンセルされてしまうと、MDMからの定期的な同期命令が届くのを待つか、手動でMDM上から命令を送るかしないとアプリをインストールさせられません。

いずれにしてもインストールするかしないかをユーザに委ねている状態ですから、台数が2桁/3桁/4桁と増えていくほどインストールの徹底が困難になることは容易に想像がつくでしょう。

MDMでアプリの配布は確かに楽になるのですが、インストールを強制させられるわけではないのです。

しかし監視モードでは、この確認ダイアログが表示されません。MDMからインストール命令が届いた途端、強制的にアプリがインストールされます。


(問答無用にインストールされる。翌朝起きるとアプリが勝手に増えているなんてことも可能)

これをアプリのサイレントインストールと言います。MDMでの設定さえ正しく行えば管理者の意図した通りにアプリインストールを徹底できるのですから、監視モードを使わない手はないでしょう。

(2) Apple Configurator2 での構成プロファイルインストール

Apple Configurator2 を使って構成プロファイルをインストールする場合、以前の記事(構成プロファイルの作成とインストールの基礎 〜Apple Configurator2を使う方法〜)で紹介した通り、端末側での操作が必要になるのでした。


(端末ユーザ側のオペレーションを必要とする)

しかし監視モード端末では、これも強制できます。

いちいちデバイス側で操作をしなくても、Apple Configurator2 から構成プロファイルがインストールされたら即設定が適用されます。(ちなみに、MDM経由のプロファイルインストールではデバイス側の確認はそもそも不要)

これを構成プロファイルのサイレントインストールと言います。

実際のところ Apple Configurator2 をメインツールにして管理運用するケースは限られますが、それでも検証やトラブル対応時に使うことはままあります。そんな時に作業効率UPに繋がるのは嬉しい仕様と言えるでしょう。

 

(B) 構成プロファイルの「監理対象のみ」の設定が使えるようになる (設定の強化)

次に制限の強化を見てみましょう。

監視モードでは、Apple Configurator2のプロファイルエディタで「監理対象のみ」と書かれた特別な設定、また構成プロファイル仕様書に supervised only と書かれた設定が使えるようになります。


(監理対象のみの項目は意外に多い。監視モードでなければ得られる恩恵は半減するということでもある)

監視モードで有効な設定には、例えば以下のようなものがあります。

  • Single App Mode (単一アプリ制限モード)
  • iOS アップデートの抑制
  • WiFi接続先アクセスポイントの制限
  • 標準アプリを非表示にする
  • Appを削除できないようにする
  • iOS を勝手に初期化できないようにする

魅力的な制限が並びますね。全て監視モードでなければ使えません。冒頭で「監視モードを知っているかどうかが提案の優劣に繋がる」と書いた意味がお分かり頂けるかと思います。

監視モードで制限できることの一覧は、以下のようにAppleが公開していますので見てみると良いでしょう。(iPhoneおよびiPadデバイスの監理対象の制限)


(監視モードでのみ制限できることが驚くほど多いことが分かる)

また、構成プロファイル仕様書を supervised というキーワードで検索して眺めてみるのもオススメです。


(Appleが公式に公開している仕様書なので、各設定のより詳細な情報を得ることができる)

一点念頭に置いておきたいのは「監理対象のみ」の項目は年々増えているという点です。

毎年iOSアップデートと共に設定項目が追加されますが、最近はほぼ追加される項目が「監理対象のみ」になっています。また、従来監視モードでなくても有効だった設定項目が「監理対象のみ」に格上げされるケースも多く見られます。

これは「業務用のiOSデバイスは極力監視モードで配備すべきである」というAppleからのメッセージであると捉えるのが順当でしょう。

 

(C) MDMや Apple Configurator2 から特別な命令を送れるようになる (制御の強化)

監視モードの端末では、通常モードではできない特別な制御も可能になります。例えば以下のようなことです。

  • (1) 再起動
  • (2) 管理対象紛失モード化

具体的にどのようなことか、以下順に見てみましょう。

(1) 再起動

監視モードの端末には再起動の命令を送ることができます。監視モードでない端末には送れません。


(MDMのBizMobileから遠隔再起動をしようとする様子。監視モードでない端末ではメニューに再起動が存在しない)

また、Apple Configurator2 からも再起動コマンドを送ることができます。

:
(監視モードになっていない端末でも再起動のメニューをクリックはできるが、再起動はしない)

ただ実際の運用では、再起動を使う機会は余り無いかも知れません。しいてあげれば Single App Mode の端末を初期状態に戻す時ぐらいでしょうか。ですが、監視モードの端末に再起動命令が送れることは覚えておいて損はないでしょう。

(2) 管理対象紛失モード化

実はiOSには管理対象紛失モードというさらに特別なモードが用意されています。監視モードの端末だけが、MDMから命令をうけてこのモードに切り替わることができます。名前の通り、端末を紛失した時に使います。

従来、端末を紛失した場合、遠隔で工場出荷時に初期化(リモートワイプ)するのが一般的な運用でした。ただこの運用では、紛失が勘違いだったとか、すぐ見つかったといった場合に「端末が見つかったは良いけど初期化された後だった」ということになってしまう可能性があったのです。

この課題を解決するのが管理対象紛失モード。MDMから命令を送ると以下のような画面になります。


(管理対象紛失モードに切り替わった端末の画面)

一度このモードに変わったが最後、以降はいかなる操作も受け付けられません。端末が見つかって利用者本人の手に戻ったら、管理者がMDMからモード解除してあげることで以下のような画面になり、再び使えるようになります。


(続けるをタップすると管理対象紛失モード化される直前の状態に戻る。もちろん監視モードのまま)

管理対象紛失モードはセキュリティと利便性を絶妙にバランスさせた機能といえます。

2つの例を紹介しましたが、このように監視モードでしか送れない特別なコマンドがあります。興味ある方は MDM Protocol reference の PDF を supervised で検索してみると良いでしょう。

 

まとめ

本稿では、監視モードとは何かについて解説しました。大きくは以下3つのことができるようになるiOSの特別なモードということでした。

  • (A) サイレントインストールが行えるようになる [インストールの強化]
  • (B) 構成プロファイルの「管理対象のみ」の設定項目を使用できるようになる [設定の強化]
  • (C) MDMやApple Configurator2 から特別な命令(コマンド)を送れるようになる [制御の強化]

管理者にとって非常に都合の良い機能だということがご理解頂けたと思います。監視モードについては以下のような関連投稿がありますので併せてご覧ください。

本サイトはACNメンバーの(株)フィードテイラーが運営するエンタープライズiOS情報サイトです

最近の投稿