macOSセキュリティの最新情報

(音楽)

おはようございます (拍手) ご参加ありがとうございます

Security Engineering and Architectureチームのギャレットです 今日はmacOS Catalinaの セキュリティの進歩についてです

お話しするのは― 多層防御のセキュリティ原理の 適用方法と macOSのセキュリティモデルの ２つの重要な部分についてです Gatekeeperと ユーザのプライバシー保護です

では多層防御から 複雑で用途の多い macOSのような製品の場合は―

完璧なセキュリティを届ける 単独の技術はありません そのため macOSは多くの異なる セキュリティ層で設計され 各層に特定の目的や目標が あります

そして我々は 毎年 皆さんの安全を守るため 各層の技術や原則を 改良しています

これが多層防御の原則です 目標は セキュリティの１つの層が システム全体のセキュリティモデルを 無効化しないことです

代わりに 異なるプロパティを持つ 複数の防御層に頼っています ある層は攻撃者の前進を 遅らせるために ある層は 攻撃可能面を減らすように 別の層は防御を容易にするよう 設計されています

今日はmacOSのセキュリティの ２つの異なる層について話します まずは悪意あるソフトウェアから 守るために設計された― セキュリティの重要な外部層である Gatekeeperについて話します

次にユーザプライバシー保護です これは悪意あるソフトウェアが Gatekeeperを回避しても 機密データやリソースに アクセスできないようにします

ではGatekeeperの話を 最初にGatekeeperが 導入された時― その目標は― 悪意あるソフトウェアの拡散を 防ぐことでした しかし時が経ち 目標は大きくなりました 今はユーザがMac上で 動かすソフトウェアを制御しながら 悪意あるソフトウェアの実行を 防げるよう設計されています

Gatekeeperは どうのようにして変化したのか Gatekeeperの意図は ２～３の単純な質問に要約されます Gatekeeperはいかにして この目標を達成したのか

Gatekeeperは ４つの点をスキャンします

まずは

１つ目は 悪意あるコンテンツをスキャンし アプリケーション内に悪意ある ソフトウェアがないことを確認します

２つ目は署名の検証です アプリケーションの 改ざんがないかを確認します

３つ目は本人確認で ローカルセキュリティ ポリシー実行のための機能です ユーザがApp Storeの ソフトウェアを動かそうとしても 他人が署名したものや 署名のないものは認めません

最後に ユーザが実際に アプリケーションを実行するかを 確認するための起動プロンプトです

まずGatekeeperは いつチェックを行うのか macOS Mojave内で― Gatekeeperは Launch Servicesを介して― 検疫済みソフトウェアの 最初の起動時にスキャンを行います 更なる理解のために検疫と Launch Servicesについて 掘り下げます 始めましょう

検疫はmacOSに 組み込まれた技術で デバイス以外から届いたファイルに マークをする機能です ファイルをダウンロードした時や iMessageから何か届いた時 またAirDropを受け取った時に ファイルは検疫されます 更にmacOSが そのファイルに 発信元のメタデータを加えます なので最初の起動プロンプトの表示に 発信元の情報が出ます 検疫はオプトイン方式です つまり アプリケーションが 検疫を許可する必要があります そしてアプリケーションが裏で ファイルをダウンロードする時には それらのファイルは 通常検疫を受けません

例外はアプリケーションが サンドボックス化された場合です サンドボックス化されていると ファイル検疫がデフォルトです

システム上のどのファイルが 検疫されるか理解できましたね ではLaunch Servicesについて 話しましょう

Launch Servicesはアプリケーションを 見つけて起動するためのもので Mac上でのアプリケーションの 起動にとって重要です FinderやDockで アプリケーションを開く時に 通常はLaunch Servicesを 経由します またドキュメントハンドラ経由や 直接URLから文書を開く時も すべてLaunch Servicesを 通ります

Launch Servicesを 経由する話をする時には こちらのFinderアイコンを 使います

Launch Servicesを 使わないロード方法もあります プロセスを開始するための NSTaskの使用や― execやposix spawnの 呼び出し― NSBundle APIを使用した プロセスへのライブラリのロードです

Launch Services以外の コードのロードの説明では このターミナルアイコンを 使うつもりです

今年の変更点について 分かりやすいように Gatekeeperについて 学んだことをまとめます

Launch Servicesで検疫済みの ソフトウェアの起動時の― Gatekeeperの動きを示しています Gatekeeperは悪意ある コンテンツをスキャンし アプリケーションが改ざんされて いないかをチェックします

そしてローカルポリシーを チェックします 署名済みアプリケーションで あることがデフォルトです 最終的にユーザに 最初の起動プロンプトを表示します

最新のmacOS Mojave 10.14.5から― デフォルトポリシーを 少し変更し Gatekeeperを通過するためには 公証を得ていることが必要になりました

まずこれを改良したのが macOS Catalinaです すべての新ソフトウェアで― 公証を必要とするよう ポリシーを拡張しています

ここで言う“新しい”とは 2019年６月１日以降に 署名もしくは 作られたものを指します

すでにあるソフトウェアは Developer ID証明書だけで 引き続きGatekeeperを通過できます しかし新しいソフトウェアは 通過できるよう公証が必要です

そして macOS　Catalinaで行った 次の改良は すべての検疫済みソフトウェアに 同じポリシーを適用するように Gatekeeperを拡張したことです ソフトウェアがどのように ロードされたかに関わらず 検疫済みであれば― 悪意あるコンテンツを含まず 改ざんもありません そして新しいソフトウェアは 公証が求められます 最初の起動時のポリシーは 若干 変更され スタンドアローンの実行ファイルや ライブラリは承認が求められません しかしバンドルされたものは 最初にプロンプトが表示されます

Gatekeeperはスキャンとポリシーを 強制するよう拡張しました macOS Catalinaの 最後の改良は ユーザを守るために Gatekeeperが 全ソフトウェアに対し 悪意がないかを検査することです

ソフトウェアが検疫済みか どのようにロードされたかによらず 悪意あるコンテンツが見つかれば ブロックされユーザに通知されます

これがmacOS Catalinaにおいて 皆さんを守るため Gatekeeperを拡張した経緯です

１つ覚えておいてください

我々の目標は Macユーザの安全を守ること 皆さんのソフトウェアの使用を 妨げることではありません

これは常に自分のシステムで 特定のソフトウェアを― 動かせることを意味します

すべての層で 我々が持つ技術とポリシーを― 毎年 たゆまず改良していることを 話しました Gatekeeperにおける 次の改良点も解説したいと思います

Security Engineeringチームは 大きな目標を持ってます Macに期待される柔軟さを 維持しながら macOSをiOS並みに 安全なものにすることです それは実に 興味深いチャレンジです １つ言えるのは―

プラットフォームセキュリティの コード署名への依存度が高まっています

もしアプリケーションが 署名を持っていなかったら―

改ざんを検出できません

更に もしバンドル署名が 実行中に壊れたら―

悪意ある改ざんと 実行中に自ら修正する― 通常の変更との区別が 非常に困難です

未来のmacOSでは 署名なしのコードは作動しません

このようにセキュリティを改善するため 皆さんができることがいくつかあります

まず検疫されてなくても 配布するすべてのソフトウェアに 署名して公証を得ること

次に 実行時にアプリケーション署名や バンドル署名を崩さないことです アプリケーションの アップデートが必要なら 正しく署名されていること 公証があることを確かめてください

最後にコードのロードは 失敗することもあります 検疫されたライブラリや プロセスをロードしようとして ユーザがキャンセルして失敗すると アプリケーションがうまく対処します

悪意あるソフトウェアの 実行を防ぐために Gatekeeperは このように拡張しました ではプライバシー保護の進展について ケリーが説明します ケリー

(拍手) ありがとう　ギャレット おはようございます ケリー･ヤンシーです ギャレットと共に働いています 去年のWWDC 2018で macOS Mojaveの プライバシー保護を紹介しました 大まかには… 失礼　まずは説明を この保護はユーザのデータへの アクセスを透明化し アクセスを制御できるよう 設計されています macOS Catalinaの 改良点を話せて興奮しています 大まかに言うと macOS Catalinaの プライバシー保護では ユーザを記録できるカメラや マイクのようなハードウェアや 写真やメールのようなユーザの 私的データへのアクセスに ユーザの同意を要します

また 他のアプリケーションの 自動実行機能も保護します アプリケーション間での データ共有を制御するためです まずは記録機能を見てみましょう macOS Mojaveでは アプリケーションのカメラ等への アクセスにはユーザの同意が必須です macOS Catalinaは更に コンテンツやキーボードの入力を記録 それにも同意が必要です 重要なことです なぜなら我々は操作や入力を 覗き見られるのを防ぎたいからです 意図的か偶然かに関わらず 口座の詳細やパスワード 連絡先情報などについて アプリケーションに覗かれたくない

では どうするか？ Screen recordingから 説明します CGDisplayStreamで ディスプレイ内容を記録する例です macOS Catalinaでは このアプリケーションが 実行される時に CGDisplayStreamを 作る関数がコールされます これはnilを返しますが ダイアログが表示されて システム環境設定の セキュリティとプライバシーで アプリケーションが画面の内容を 記録する許可を促します

他のアプリケーションウインドウの コンテンツを読む時も同じです これはウインドウのコンテンツを ディスク上にイメージ保存する関数です CGWindowListCreateImageでは 呼び出し元のアプリケーションや デスクトップの背景画像や メニューバーに属さない― ウインドウIDが渡された場合 nilが返ります これは背景画像で アイコンもデスクトップ上の ファイル名も含みません

Screen recordingを 承認するようユーザに指示する― 承認画面は 表示されないこともあります CGWindowListCreateImageや CGDisplayStreamが 承認を得られずに最初に失敗した時のみ 表示されます

もう１つ扱いたい関連テーマは ウインドウメタデータです アプリケーションは Core Graphicsを使用する― ウインドウに関する メタデータを照会できます

返却されるメタデータには ウインドウのサイズと位置と固有ID 属しているアプリケーションの 名前とIDが含まれます

しかしユーザが― Screen recordingを 事前承認してないと ウインドウ名と共有状態は 得られません これはアプリケーションが アカウント名やURLなどの 機密のデータをウインドウ名に 含めることがあるためです そして CGWindowListCopyWindowInfoは オーソリプロンプトを作動させず 返却するメタデータを選別します たとえばアプリケーションで ウインドウ名を必要としているが 返却されたメタデータが ウインドウ名を含んでない場合は ユーザにプライバシーと セキュリティの設定を促したいでしょう

これはデスクトップの 背景画像用の― ウインドウの固有IDを得る 関数の例です 今回もデスクトップ上のアイコンを 含みません

CGWindowListCopyWindowInfoを 使って この関数は最初に画面上の 全ウインドウのリストを得ます しかし その後― Core Graphicsが使用するウインドウ レベルかＺオーダーを取得します

次に全ウインドウのリストから デスクトップ背景の レベルのウインドウを選別します インターネットで探すと 機密情報が含まれる可能性のある― kCGウインドウ名で選別を行う コードサンプルが見つかります これにはScreen recordingの 事前承認が必要です しかしウインドウ名ではなく ウインドウレベルによって デスクトップ背景ウインドウを 識別することで ユーザがScreen recordingの 事前承認をしなくても機能します これはユーザ体験において アプリケーションの設計の小さな変更が 大きな違いを生むという例です

macOS Catalinaでは許可なしに 画面のコンテンツを記録できません アプリケーションはウインドウの コンテンツを自由に記録できます メニューバーや デスクトップ背景画像もです しかし全画面や別のアプリケーションの コンテンツの記録を許可するには 環境設定のセキュリティと プライバシーのペインを使います

macOS Catalinaで 守られる他の記録機能は キーボードです

ユーザはキー入力が― 操作してるアプリケーションにのみ 送られるものと思います アプリケーションは使用時のみ キー入力を求めます 実際 アプリケーションが標準の UIコンポーネントを使っている場合 キーボードイベントは自動的に アプリケーションに送られます 配信の際にそういうイベントを 妨害するアプリケーションもあり NSApplicationを派生させ sendEventメソッドを上書きします addLocalMonitorForEvents関数も 使えます

しかしキーボードイベントの監視は ユーザの承認が必須です これはキー操作の コールバックを行うために― CGEventTapCreateを使った例です このコードが 初めて実行される時― CGEventTapCreateは 失敗してnilが返ります

一方ユーザには環境設定の セキュリティとプライバシーで キーボードイベントの監視の 承認を促す画面が表示されます

kIOHIDRequestTypeListenEvent パラメータと IOHIDCheckAccessの 機能を使って アプリケーションは オーソリの状態を確認できます

またアプリケーションは IOHIDRequestAccess関数を使って イベントタブを作成して 表示することなく― 承認ダイアログの表示を 求められます

要約すると macOS Catalinaはユーザに アプリケーションがコンテンツを 記録する許可を求めるのです ではmacOSはどのように ファイルへのアクセスを 守るのでしょう

Mojaveでのアプローチを継続しながら macOS Catalinaは ２つのレベルのプライバシー保護を 提供します １つ目はアプリケーションが アクセスするユーザデータです macOSはデータを共有する前に ユーザの同意を確認します ２つ目はファイルシステムの実装で 扱われるユーザデータです これはAPIではなく メールやメッセージなどです これらへのアクセスには 高い壁が存在します 特別なアプリケーションしか アクセスできません まずはアクセスへの同意が 必要なものの説明を

macOS Mojaveはユーザの― 連絡先などへのアクセスの同意 を導入しました こんな感じです アプリケーションが ファイルにアクセスすると出ます

Screen recordingで見た 画面とは違います アクセスを拒否して ユーザへ警告するのではなく ユーザの承認の有無を待ち 呼び出し元のスレッドは ブロックされます

macOS Catalinaでは APIデータについて 追加カテゴリで これらを補完しました これらは文書を 保存するための場所です

ユーザはダブルクリックしたり― パネルを介したりして選択します

デスクトップと書類フォルダの保護は 最重要です 多くの方がファイルを保存します アプリケーションがファイルを 保存するダウンロードフォルダもです

iCloud Driveやサードパーティの― クラウドストレージの文書も 保護します 私はフロッピーディスクを 想像しましたが ここではUSBメモリや 外部ディスクを含む― 取り外し可能ボリューム上の ファイルのことです

写真家なら分かると思いますが 外部ディスクやNASの中に 人生が詰まってる人もいます

現在 macOS Catalinaはファイルを 保存する場所を守っています

さて 保護された場所に 新しく文書を作るのにも 既存コンテンツを読み取るのにも ユーザの同意はいりません たとえば ファイル転送アプリケーションは 同意なしに 新しいファイルを保存し続けられます

またユーザのプライバシー保護では ユーザの意図をサポートします

ファイルをダブルクリックした時や 他のアプリケーションから ドラッグ＆ドロップをした時などです

ユーザが どんなアクションをしても

保護された場所にある ファイルであれば アプリケーションは同意なしに ユーザが選んだ文書にアクセスできます

macOS Catalinaのユーザの 意図の推測と同意を見てみましょう

失礼 ユーザの同意は 事後対応型です アクセスの承認はアプリケーションが 読み書きを試みたあとのみですが ユーザの意図は事前対応型で アプリケーションが読み書きする前に アクセスが承認されます

そしてユーザの同意プロンプトは ワークフローを中断させますが ユーザの意図は標準UIの インタラクションから推測します こうした中断を最小限にするには たとえばユーザの同意を デスクトップの全ファイルに適用します 一方 ユーザの意図は 関わるファイルからのみ推測されます つまり２つは相容れません そのため アプリケーションが ユーザが選んだものにアクセスする限り 同意プロンプトは必要ありません プライバシー保護された ファイルへのアクセスは― 自分で作ったか ユーザが選択したもの以外は ユーザが承認する必要があります アプリケーションが 選択してないサイドカーファイルに アクセスするというシナリオを考えます たとえば自動でムービーファイルに 隣接した同じ名前の― 字幕ファイルを開く場合です

NSFileCoordinatorで 関連項目サポートを使うことで １つのファイルに対する許可を― 他のファイルにも 与えることが可能です

NSFileCoordinatorを 使うためには サイドカーファイルの 拡張子の宣言が必要です CFBundleDocumentTypes Info.plistキー そしてNSIsRelatedItemTypeを ブーリアンtrueに それからコード内の NSFilePresenterを派生させて primaryPresentedItemURLを 設定します アプリケーションがすでにアクセスを 許可されているものです またpresentedItemURLを アクセスしたいサイドカーファイルに サイドカーファイルと 選択のファイルは 拡張子が異なっても 他の要素は同一であるべきです

最後にNSFileCoordinatorを 作ります そしてcoordinateメソッドを 呼び出せば このブロック内でサイドカーファイルに アクセスが可能に

ユーザが同意プロンプトなしに 自身が選択したファイルと 同名だが別の拡張子を持つファイルに アクセスする方法を説明しました ユーザの意図を安全に推測するために Open and Saveパネルは 常にプロセス外に置かれてます 結果としてアプリケーションに 影響を与える可能性がある― クラスの継承と ビュー階層は変更されました

アプリケーションはもう OKメソッドを呼び出して プログラムで パネルを許可できません

NSOpenSavePanelDelegateメソッドも 変更されました アプリケーションは もう選択を 書き換えられません

またアクセス時にユーザの 同意プロンプトが出現し得ます ユーザがパネル操作中で まだファイル選択されて いないからです ゆえにアプリケーションは 未承認です

アプリケーションは これらのAPIを使い 同意なく読み書きできるのか

そしてアプリケーションが 自ら作ったファイルか ファイルを開くイベントを介して 受け取るか または― ドラッグ＆ドロップした ファイルにアクセスする限り ファイルへのアクセス承認が推測され 同意は必要ありません しかし同意プロンプトが 求められる場合 新たに保護される所は 目的の文字列がサポートされます 目的の文字列は 同意プロンプトが表示された時に アクセスコンテキストの説明として Info.plistで指定できます

これらのカテゴリに対する 目的の文字列は任意ですが もし守られた場所に アクセスするなら そこに目的の文字列を 設定することを勧めます アプリケーションのアクセス理由を ユーザに知らせるためです アプリケーションのテストで不意に 同意プロンプトが出現したら コンソールで サンドボックス違反の結果を見れば アクセスしようとしていたファイルと 同意プロンプトを求める原因となった バックトレースが分かるでしょう

macOS Catalinaがどうやって 文書を守るのか 標準UIがアクセスする文書の推測に どう関わるかを説明をしました macOSがシステムを使って 管理するデータをどう守るか どうすればアプリケーションが アクセスを要求できるのか

macOS Mojave以降で 守られているデータです ディスク管理や バックアップのソフトウェアは ファイルの内容に関わらず 機能します これらのアプリケーションは ファイルに読み書きできるか 判断するために さっきのようなAPIを使います アプリケーションに適したものによって アクセス不可のパスをスキップしたり 全機能を得るため アプリケーションを 承認したりするよう指示します

ディスク全体への アクセス承認画面です

ここでディスク全体へのアクセスを アプリケーションに許可するために macOS Catalina内で行った 機能強化を説明します 今までどおり手動でも アプリケーションを加えられます ユーザが特権ヘルパーを 見つけるのは難しいそうです だからmacOS Catalinaでは ディスク全体への アクセスが許されず 拒否された実行ファイルは 未チェックです ファイル名から特定された ヘルパーを見てみましょう

ヘルパーがバンドルに 埋め込まれていると バンドルのInfo.plistを特定する アイコン名が表示されます

ディスク全体へのアクセスが 事前に許可されたアプリケーションは アクセス可能です ファイルマネージャを使用して オーソリをテストできますし 環境設定のセキュリティと プライバシーペインに ユーザを導くことができます

macOS Catalinaでは― ディスク全体へのアクセスを 必要とする種類のデータは ゴミ箱も含めるよう 拡張されています

ファイルをゴミ箱に移すと 消えると思っている人が多いです だからゴミ箱を漁ろうとはしません

このサイズだと恐ろしい

他のカテゴリ同様 ゴミ箱には 多くのデータがあります しかしゴミ箱はファイルの主体であり ファイルを扱うための APIを備えてます ゴミ箱にファイルを移す このようなAPIです ファイルマネージャの trashItemのAPIを説明します APIはゴミ箱に移す ファイルのURLを引数に持ちます

呼び出し元は ファイルへのアクセスが必要で アクセス許可がないファイルは ゴミ箱に移せません

移動できたAPIの outResultingURLパラメータには ゴミ箱内のNSURLが入ります まだそのURLへアクセス可能です 移す前でも あとでも アクセスできます よってFileManager APIは ゴミ箱からファイルを戻せます

アプリケーションは ゴミ箱を見るために ディスク全体へのアクセスを 必要とします ファイルをゴミ箱へ移したり ゴミ箱内にアクセスするのに オーソリは必要ありません

最後に自動化について 手短に

macOS Mojaveはシステムなどの 自動化への同意の要請を導入しました これはアプリケーションの不正使用を 防ぐのに重要です

まずは合成イベントがあります 合成入力イベントはキーボードや マウス入力を助けるための― アクセスシビリティ ソフトウェアに使われます

同意ダイアログや 意図の推測などは すべてユーザの入力頼みです 重要なのは合成入力イベントを 承認できるのは プロキシとしての アプリケーション限定です

これはキー押下とキーリリースを シミュレートするコードの一例です

まずコードが実行され

ユーザを装って イベントをポストすると― そのイベントは廃棄されます そして環境設定のセキュリティと プライバシーペインで アクセシビリティ機能を オーソリすべきだと 警告が表示されます

先ほどキーボードイベントの時に このサンプルコードを見ました

listenOnlyを defaultTapに変更したら

CGEvent.tapCreateは コールバックでタブを作成 イベントストリームを変更できます どのイベントが― システム全体に送られるかを アプリケーションで変更できます listen-onlyイベントでは 入力監視のオーソリが求められますが イベント変更アプリケーションには アクセシビリティ機能の オーソリが求められます

IOHIDCheckAccess関数を使って 入力イベントを合成することを ユーザが認めているかを― アプリケーションで テストできます これはキーボード入力監視のオーソリを チェックするAPIと同じですが ここでは kIOHIDRequestTypePostEventを渡します

これが合成イベントを介した 自動化でした ではAppleイベントを介した 自動化に進みます

ユーザは他のアプリケーションの 動きを制御するために アプリケーションがAppleScriptなどを 使うことに同意が必要です 同意プロンプトは どのアプリケーションが 他のアプリケーションの影響下で 動いているかを明確にします

Appleイベントの例外もあります

送信元のプロセスにデータへの アクセスを許さない等です これらはNSWorkspaceの APIを介して公開されています

AEDeterminePermission ToAutomateTarget関数は Appleイベントの送信にオーソリが 必要かをテストするのに使えます これは呼び出し元がAppleイベントを 送信可能かをテストする例です

またブーリアンのtrueを渡すことで 必要に応じて承認プロンプトの 表示を要求できます プロンプトが表示されると 呼び出しスレッドはブロックされるので メインスレッドでは やめましょう このAPIは呼び出し元がAppleイベントを ターゲットに送るのを許可されてるか Appleイベントを送信しようとすると 同意プロンプトが表示されるのか Appleイベントの送信によって この時 未起動のターゲットが 起動するか またはエラーが発生したかを 示すOSStatusコードを返します 非常に低レベルのAPIです

自動化の前のユーザの同意 アプリケーションにおける 同意の有無の判断方法 それにどう調整するかについての 概要でした

macOS Catalinaでは 画面内容の記録に ユーザの同意が必要です これはカメラとマイクの 保護機能の強化です デスクトップや書類や ダウンロードのような― 共通の文書の保存場所も 保護されます iCloud Driveや サードパーティのストレージ 取り外せるネットワークボリューム ゴミ箱など

プライバシー環境設定や ポリシーコントリールやMDMは macOS Catalinaに新たに守られる リソース向けに拡張されました アプリケーションの 動作テスト中に プロンプトを再び表示させたいと 思うことがあるでしょう プロンプト状態をリセットするには tccutilコマンドラインツールで 左側に表示されている サービス名を使用します

ギャレットからは Gatekeeperの強化について そしてmacOS Catalinaの― ユーザプライバシー保護に ついて話をしました ではまとめに入ろうと思います 全ソフトウェアに 署名 公証を忘れないこと そして一度 署名したら バンドルを修正しない 修正が必要な時は 変換後の 別のバンドルにも署名すること

ユーザプライバシー保護のためには 標準UIを活用してください エラーが返ったら それに対処を ユーザが同意を拒否すると APIはエラーを返します ユーザがアプリケーションに 個人データのアクセスを許可したら プライバシー保護の責任は 皆さんに移るのでご注意を

残りのWWDCを楽しんでください macOSにおけるセキュリティ保護に 関して質問があれば このあとの セキュリティラボへどうぞ ありがとうございました (拍手)