ストリーミングはほとんどのブラウザと
Developerアプリで視聴できます。
-
組織におけるパスキーの導入
組織の管理された環境でパスキーを活用する方法を紹介します。iCloudキーチェーンの管理対象のApple IDへの対応を通じて、パスキーが企業の環境でどのように活用できるかを探ります。また、Apple Business ManagerとApple School Managerのアクセス管理機能を使って、管理者が特定のデバイスのパスキーを管理する方法も紹介します。
関連する章
- 0:00 - Introduction
- 1:20 - Benefits of passkeys at work
- 6:41 - Managing passkeys at work
- 14:33 - Demo
- 15:42 - Next steps
リソース
関連ビデオ
WWDC23
WWDC22
-
ダウンロード
♪ ♪
Enterprise Servicesチームの エンジニアリングマネージャー Alex Sokolovです 今日は仕事用パスキーの導入に ついてお話したいと思います パスキーとは何か また業務において― パスキーが管理された環境での 要件に対処するために 使用できる新しいツールである ことについて説明します
パスキーはパスワードの 代わりになります サインインがより速く簡単になります Touch IDまたはFace IDを 使用して認証するだけで完了 強力かつ各アプリやWebサイトに 固有のものであることが 保証されているため はるかに安全であり フィッシング攻撃に対しても 高い耐性があります iOSやiPadOSにmacOSに組込みの パスワードマネージャーを使用して パスキーを保存する場合iCloudキーチェーンを 介してAppleデバイス間で 同期されるため 各デバイス間で 即座に利用できるようになります 「パスキー」は「パスワード」という 単語と同じように一般名詞であり 業界標準用語であるため 小文字の表記になり FIDOアライアンスやGoogleや Microsoftなども使用しています パスキーがどのように機能するかを 簡単に要約する WWDC22の「Meet Passkeys」 セッションもご覧ください パスキーが導入された際 パスワードよりも 優れている点について 詳しく学ばれたと思うので 今日はハッカーによる一般的な 攻撃からパスキーを使用して 従業員アカウントを保護する 方法について説明しましょう 今日企業の懸案事項として 挙げられる3点として フィッシング攻撃 アカウント情報の盗難攻撃 2ファクタ認証バイパス攻撃が あります それぞれについて見ていきましょう 従業員に対するフィッシング攻撃は 企業が防御しなければならない 最も重大な攻撃の1つです それは多くの場合大規模な侵害を もたらす攻撃となります 10億件以上のフィッシング攻撃を調査した 2022年のVerizonデータ侵害 調査報告書によると 従業員の2.9%が実際にフィッシング リンクをクリックしており 結果自体は時間経過しても 比較的安定してはいます でもこのままでは犯罪者が攻撃を 続けるのに十分すぎる数値です この問題は企業の規模が 大きくなるにつれて悪化します 100人の会社でフィッシング リンクをクリックするのは3人だけです この数字は500人の企業では15となり 1,000人の会社では29人です それほど大きな数字ではないと 思うかもしれませんが たった1つのアカウントに対する フィッシング攻撃でも 多くの場合これが全体的な侵害へ の最初の侵入ポイントとなります ユーザーが何かを入力している ときはいつでも だまされて間違った場所に 情報を入力する可能性があります パスキーを使用すると何も入力 する必要がなく 各パスキーは使用されるWebサイト またはアプリにリンクされています ユーザーがだまされて間違ったWebサイトで パスキーを使用することはありません パスキーを使用するとアカウント 情報フィッシングはなくなります 毎週 攻撃者がパスワードを盗み得た サーバ侵害の案件についてニュースがあります 約4,000件の侵害を分析したレポートによると 2022年に発生した侵害の40%には 盗まれた認証情報が使用されていました パスワードの場合サーバに ハッシュが保存されますが ハッシュは盗まれたり クラックされる可能性があり 平文のパスワードでは攻撃者に 入手されてしまいます その後侵害Aのパスワードを 使用してサービスBや Cなどへのログインを試みる ことが可能になってしまいます サーバ侵害と認証情報攻撃が 攻撃者にとって好循環となるわけです サーバに保存されるのは 公開キーのみであるためパスキーは このサイクルを打破します パスキーの使用でサーバから盗む価値の あるものはなくなります 答えは追加の要素を重ねること だと思うかもしれませんが 2ファクタ認証では 想像されるようには ユーザーは保護されません 攻撃者はユーザーをだまして 2FAとも呼ばれる一般的な 2ファクタ認証の3つの形式を バイパスさせます SMSコードはパスワード同様 簡単にフィッシングされる可能性があります 時間ベースのワンタイムパスワードも 同様にフィッシングされる可能性があります プッシュ通知はフィッシング攻撃を 受けることはありませんが プッシュ疲労につけ込んだ攻撃を 受けやすくなっています 最近の攻撃では2FA脆弱性が 悪用されました ハッカーは従業員に継続的に プッシュ通知を送信し続け 最終的には従業員を騙して プッシュ通知を受け入れさせました パスワードは複数の方法で 破られていたため パスワードの上に追加の要素が 重ねられたわけです パスキーはこれらの状況に対する 単なる絆創膏ではありません 不完全な主要素を設計上安全な 新しい主要素に置き換えます パスキーを使用すると主要素は 打破されなくなります パスキーで保護されているアカウントに SMSやTOTPにプッシュ通知などの 脆弱な2つの要素を重ねても それ以上のセキュリティは追加されません パスキーのセキュリティ上の利点 に感心しながらも 優れたセキュリティには高い代償が 伴うのではという懸念ももっともです 優れたセキュリティの実現には 使いやすさを 妥協する必要があると思われるかもしれません 体験を並べて比較してみましょう 新しいパスワードの作成と パスキー作成の違いです ご覧のとおりパスキーの作成は 大幅に高速化されており パスワードを作成するよりも簡単です Face IDを認証するだけで完了します 作成について見てきましたが サインインを比較してみましょう パスワードの場合ユーザーは パスワードを覚えて入力します パスキーを使用すれば Face ID認証だけで完了です パスワードマネージャーはサインインの 体験を向上させるのに役立ちますが 最高のパスワードマネージャーでも パスキーのスムーズなサインインには 太刀打ちできません セキュリティの向上と 使いやすさの向上の間で どちらかが犠牲になると 考えられるかもしれませんが パスキーでは 優れたセキュリティと 優れたユーザーエクスペリエンスを 同時に実現できるのです これには理解しなければならない ことがたくさんあるので 企業にとってのパスキーの利点を もう一度まとめてみましょう まずフィッシングがなくなります 現在従業員を保護するために使用している パスワードや2FAの一般的な形式は フィッシングの対象となることがあります パスキーにはフィッシング耐性があります サーバからのアカウント情報の 盗難がなくなります パスワードハッシュは侵害によって サーバから盗まれる可能性があります パスキーを使用するとサーバには 公開キーが保存されるだけなので サーバから盗む価値のあるものは なくなります そして素晴らしいユーザーエクスペリエンスが 実現されます パスワードを使うと 従業員は 難易度の高いパスワードにしたり 変更頻度要件を満たさなければなりません パスキーを使用するとFace IDまたは Touch IDを使用するだけで完了です パスキーは双方にとって有利です 業務用のアカウントを保護するための より安全な認証情報と 従業員に好まれるユーザー エクスペリエンスの組み合わせです ただし 組織のIT管理者としては 職場でもパスキーを使用して 同様の優れたエクスペリエンスを 提供したいところですが 管理された環境には 独自の要件があります これらの要件とその対処法について 説明しましょう まずiCloudキーチェーンと パスキーを使用する Apple IDアカウントを管理します 次に従業員の個人デバイスではなく 組織で管理するデバイスにのみ パスキーを同期したいと考えます 仕事用パスキーはユーザーの個人の Apple IDではなく IT部門が管理する管理対象Apple IDに 紐付けられた iCloudキーチェーンに保存することを 希望されるでしょう パスキーを他の場所ではなく iCloudキーチェーンに 確実に保存することも可能になります 次にパスキーの作成が管理対象デバイスで 行われていることを証明書利用者に 証明したいと考えます 従業員が相互に仕事用アカウント情報を 共有できないよう パスキーの共有をオフにします これらの要件に対処するために使用 できる新しいツールをご紹介します 次の3つのトピックについてお話します 管理対象Apple IDの利用と パスキーの同期場所の管理 そして管理対象デバイス上での 仕事用パスキーの作成です 管理対象Apple IDは組織によって 所有および管理され Apple Business Managerまたは Apple School Managerで作成されます 管理対象Apple IDはmacOS SonomaとiOS 17にiPad OS 17の iCloudキーチェーンをサポートします 管理対象Apple IDを使用すると ユーザーはiCloudキーチェーンで 全デバイスでパスキーによるユーザーの アカウントを管理が可能です 管理対象Apple IDのiCloudキーチェーンに 保存のパスキーは共有できません 管理対象Apple IDのその他の 素晴らしい改善点については 「Do More with Managed Apple IDs」 セッションをご覧ください IT管理者はApple IDの管理に加えて パスキーを同期するデバイスを制御し 管理しているデバイスでのみ 同期を許可したいと考えます Apple Business Managerと Apple School Managerには 新しいアクセス管理機能があります 管理者が管理できるのは2つです 1つ目はどのデバイスで従業員が 管理対象Apple IDを使用して サインインできるかを IT管理者が管理できるようにします デフォルトのオプションは すべてのデバイスで より高いセキュリティを確保するオプションは 管理対象デバイスのみで ユーザーが個人のデバイスを職場に 持ち込む場合にも機能します 最後は管理対象の監視対象で 従業員にデバイスを提供する組織に 最高レベルのセキュリティを 提供できます また IT管理者は iCloudキーチェーンのパスキーも含め どのデバイスにiCloudコンテンツを 許可するかを制御でき 先に述べた3つの便利なオプション つまり すべてのデバイス または管理対象デバイスのみ あるいは管理対象かつ監視対象デバイスのみ から選べます IT管理者はこれらの制御により 業務専用のパスキーが管理対象デバイスにのみ 同期するよう管理できます デバイス管理サーバはこの機能の サポートを実装する必要がありますが Apple Business Essentialsでは すぐに使用できます 次にIT管理者が仕事用デバイス上の パスキーを管理して 特定のパスキーを仕事用デバイスのみに 限定する方法についてお話しします 管理対象デバイスでの業務に パスキーの作成を要求したいと考えています 具体的にはパスキーが 管理対象Apple IDの iCloudキーチェーンに保存 されていることを確認し すべてのデバイス間でパスキーの 同期を提供して パスキーが管理対象デバイス上で 作成されたことを証明します これは宣言型デバイス管理を 使用して行えます 宣言型管理の改善に関する詳細は 「Explore Advances in Declarative Device Management」をご覧ください ここではパスキーを管理するための 新しい構成に焦点を当てます 宣言型デバイス管理にはパスキーを 安全に生成するために使用できる 新しいエンタープライズパスキー 認証構成があり デバイス上でユーザーが構成で指定された サイトにアクセスしたときに表示されます 構成はIDアセットを参照します 次に関連付けられたIDを使用して 生成されたパスキーの 標準Web認証が実行されます Web認証の証明書利用者は この証明書を検証し 関連サイトへのアクセスを許可できます 次のスライドでこのプロセスについて 説明します これは特定のパスキーの作成が 管理対象デバイス上のみに 制限できることを意味します また先ほどの同期制御と 組み合わせることで パスキーがどのデバイスで同期するかを 制御することもできます この機能はiOSとiPadOSに macOSで利用可能です これはパスキー認証構成の構成例です デバイスに送信される一連の宣言で サーバによって提供される IDアセットへの参照が含まれます 構成がアクティベートされると アセットが解決され 結果のIDがキーチェーンに 保存されます 「RelyingParties」属性は このIDがWeb認証パスキー認証に― 使用される場所を示します 組織におけるデバイスの 構成例を見てみましょう まずMDMサーバはパスキー認証構成と IDアセットをデバイスに送信し アクティベートされていることを確認します アクティベートされるとID証明書が 組織の認証局サーバから プロビジョニングされます その後のいずれかの時点で ユーザーはWebサイトにアクセスします Webサイトはアクセスのための パスキーを要求します 証明利用者はエンタープライズ認証で 作成された新しいパスキーのみを受け入れ 他のすべてのパスキーは拒否する ことを示せます デバイスは新しいパスキーを生成し プロビジョニングされたID証明書を 使用してそれを証明し Webサイトに返します WebサイトはWeb認証の エンタープライズ認証ペイロード内の デバイス証明書が 組織の認証局にトレースバックできることを チェックすることで認証状況を検証できます これによりパスキーがこの組織が 管理するデバイス上で 作成されたことが証明書利用者に 証明されます これを可能にするためには 証明書利用者は組織にとって どのCA証明書を信頼すべきかを 明らかにする必要があります これは組織管理者がCA証明書の コピーを証明書利用者に アップロードするなどの 方法で実現できます 証明書利用者はパスキーの 作成時のみ証明書を検証 その時点からパスキーは追加 認証を必要とせずに その信頼構造で使用できます この方法で作成されたパスキーは 管理対象Apple IDの iCloudキーチェーンに保存されます ハードウェア認証ではありません 管理対象デバイスの認証に関する詳細は 「What’s New in Managing Apple Devices」をご覧ください 証明書利用者はWeb認証 パスキー作成応答内の 認証ステートメントを 確認する必要があります まずAAGUIDが画面上の値と 一致するかを確認してから それがAppleデバイスからの ものであるかを確認します 次に3つの項目で構成される認証 ステートメントを確認します 暗号アルゴリズムを 識別する数値ですが AppleプラットフォームのES256では、 これを常に-7に設定してください 次に認証署名を含む バイト文字列があります 最後に認証証明書と あればその証明書チェーンを含む 配列がありそれぞれX.509形式で エンコードされています 証明書ステートメントの 詳細については Web認証の公式ドキュメント 「Web Authentication Packed Attestation Statement」 を検索・参照してください この新しい宣言型デバイス 管理パスキー認証により IT管理者は証明書利用者が 認識して信頼できる 仕事用の特定の証明済み パスキーを作成できます またこれによりこれらのパスキーが ユーザーの個人Apple IDではなく 管理対象Apple IDの iCloudキーチェーンに 確実に保存されます iCloudキーチェーンをサポートする 管理対象Apple IDにより Apple Business Managerおよび Apple School Managerの アクセス管理機能と 宣言型デバイス管理構成による 仕事用パスキー管理のすべての 要件に対処できます 実際のパスキーを見てみましょう 所属先のIT管理者から Tailscaleの ネットワークを管理したいと 打診されました パスキーによるサインアップが いかに簡単かを見てみます まずパスキーの名称を選択します 次に「パスキーを作成して参加」 をタップします パスキーは管理対象Apple ID iCloudキーチェーンに保存 他のデバイスでも 使用できるようにします 最後に「続行」をタップし Face IDでサインイン これだけでネットワークを管理 できるようになりました 組織では管理対象デバイスでもパスキーを 作成する必要があるため 誤って個人の携帯電話で パスキーを作成しようとすると デバイスが組織による管理でない というエラーが表示されます もちろんこれはパスキー認証で 実現されます 仕事用の携帯電話に戻り サインインし直すのはさらに簡単です 「パスキーでサインイン」 ボタンをタップすると ご覧のとおり携帯電話に パスキーが保存されていますが それは以前このWebサイトで 使用したものです そこで「続行」をクリックし Face IDでサインインできます
では 仕事用パスキー導入のための 新機能をおさらいしましょう 同期先のデバイスを管理しながら 管理対象Apple ID向けの Web認証のエンタープライズ認証で パスキーの作成を制御できます パスキーを使用すると フィッシングやアカウント情報の盗難などの 攻撃から会社を守ることができ 同時に従業員とって便利なユーザー エクスペリエンスも提供されます これらの改善はすべて皆様からの フィードバックに基づいてます 今後もぜひご意見をお寄せください ご視聴ありがとうございました ♪ ♪
-
-
11:07 - Example passkey attestation configuration
// Example configuration: com.apple.configuration.security.passkey.attestation { "Type": "com.apple.configuration.security.passkey.attestation", "Identifier": "B1DC0125-D380-433C-913A-89D98D68BA9C", "ServerToken": "8EAB1785-6FC4-4B4D-BD63-1D1D2A085106", "Payload": { "AttestationIdentityAssetReference": "88999A94-B8D6-481A-8323-BF2F029F4EF9", "RelyingParties": [ "www.example.com" ] } }
-
13:12 - WebAuthn Packed Attestation Statement Format
// WebAuthn Packed Attestation Statement Format attestationObject: { "fmt": "packed", "attStmt": { "alg": -7, // for ES256 "sig": bytes, "x5c": [ attestnCert: bytes, * (caCert: bytes) ] } "authData": { "attestedCredentialData": { "aaguid": “dd4ec289-e01d-41c9-bb89-70fa845d4bf2”, // for Apple devices <…> } <…> } <…> }
-
-
特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。
クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。