Deploy passkeys at work

ハイライト

Passkeys は、iCloud キーチェーンのエンタープライズ認証設定、デバイスアクセス管理制御、および管理対象 Apple ID による宣言型デバイス管理をサポートしており、企業はフィッシング攻撃、認証情報の盗難、および 2FA バイパスを防止しながら、管理対象デバイスにパスワードなしのログインを安全に導入できます。

主要内容

企業が直面する 3 つの主要なセキュリティ脅威

企業が毎日直面している主な攻撃は 3 つあります (01:35):

フィッシング攻撃

Verizon の 2022 年データ侵害調査報告書によると、10 億件を超えるフィッシング試行のうち、従業員の 2.9% がフィッシングリンクをクリックしました。企業が大きくなるほどリスクは高くなります。100 人の企業では約 3 回、500 人の企業では 15 回、1,000 人の企業では 29 回のクリックが発生します。フィッシング攻撃の成功は、多くの場合、本格的な侵入の出発点となります。

パスキーを使用すると、この問題が解消されます。入力するものがなく、各パスキーは本質的に特定の Web サイトまたはアプリに関連付けられており、ユーザーが間違った Web サイトでパスキーを使用することはありません (02:47)。

資格情報の盗難

2022 年のデータ侵害の 40% には、認証情報の盗難が関係しています。パスワードサーバーに保存されるのはハッシュ値です。ハッシュが盗まれて解読されると、攻撃者は Web サイト A のパスワードを使用して Web サイト B および C にログインしようとします。

パスキーはこのサイクルを打ち破ります。サーバーは公開キーのみを保存し、盗む価値のあるものは何も保存しません (03:39)。

2 要素認証バイパス

SMS 確認コードと TOTP (時間ベースのワンタイムパスワード) はどちらも、パスワードと同様にフィッシングされる可能性があります。プッシュ通知はフィッシングできませんが、「プッシュ疲労攻撃」の影響を受けやすくなっています。攻撃者は、ユーザーが誤ってプッシュ通知を受け入れるまでプッシュ通知を送信し続けます。

Passkeys は、根本的に壊れた古いキーを、設計上安全な新しいキーに置き換える別のパッチではありません (04:35)。

安全性と経験のバランス

パスキーの作成は、パスワードを作成するよりも速くて簡単です。ログインするときにパスワードを覚えたり入力したりする必要はなく、Face ID または Touch ID (05:17) だけで済みます。

###エンタープライズ環境の特別なニーズ

IT 管理者には、パスキーを展開する際に 4 つの固有のニーズがあります (06:41)。

iCloud キーチェーンとパスキーを使用して Apple ID アカウントを管理する
パスキーの同期を許可するのは管理対象デバイスのみであり、従業員の個人デバイスには許可しない
有効なパスキーが管理対象 Apple ID の IT 管理の iCloud キーチェーンに保存されていることを確認します。
パスキーが管理対象デバイス上で作成されたことを証明書利用者に証明します。
パスキー共有機能をオフにする

管理対象 Apple ID は iCloud キーチェーンをサポートします

管理対象 Apple ID は、組織によって Apple Business Manager または Apple School Manager で作成および管理されます。 macOS Sonoma、iOS 17、iPadOS 17 以降、管理対象 Apple ID は iCloud キーチェーンをサポートします (07:50)。

利点:

ユーザーはすべてのデバイスでパスキーの同期エクスペリエンスを得ることができます
IT 部門がこれらのアカウントを管理できる
管理対象 Apple ID の iCloud キーチェーンのパスキーは共有できません

デバイスアクセス管理制御

Apple Business Manager と Apple School Manager には、2 つの制御方法を備えたアクセス管理機能が追加されました (08:34):

従業員が自分の管理対象 Apple ID でサインインできるデバイスを制御します:

任意のデバイス (デフォルト)
管理対象デバイスのみ (BYOD シナリオに最適)
管理対象の監視デバイスのみ (最高のセキュリティレベル、組織が発行したデバイスに適しています)

iCloud コンテンツ (iCloud キーチェーンのパスキーを含む) を同期できるデバイスを制御します:

上記と同じ 3 つのオプションがあります。

デバイス管理サーバーは、Apple Business Essentials がすぐに提供するこれらの機能のサポートを実装する必要があります。

Enterprise Passkey 認証構成

宣言型デバイス管理により、エンタープライズパスキー認証構成が追加されます (10:07)。この構成では次のことが可能です。

デバイス上でユーザーのパスキーを安全に生成します
ユーザーが構成で指定された Web サイトにアクセスするとトリガーされます
標準の Web 認証認証を実行するために使用される ID 資産を参照します。
関連 Web サイトへのアクセスは、証明書利用者の検証と認証後に許可されます。

構成例:

{
    "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"
        ]
    }
}

キーポイント:

AttestationIdentityAssetReference参照アイデンティティ資産 -RelyingPartiesこの ID を認証に使用する Web サイトを指定します
構成のアクティブ化後、アイデンティティ証明書がエンタープライズ認証局サーバーからプロビジョニングされます。

認定プロセス

MDM サーバーは、パスキー認証構成と ID 資産をデバイスに送信します。
構成のアクティベーション後、エンタープライズ CA サーバーから ID 証明書をプロビジョニングします。
ユーザーが Web サイトにアクセスし、Web サイトがパスキーを要求します。
依拠当事者は、エンタープライズ認証を使用した新しいパスキーのみを受け入れるように指示できます。
デバイスは新しいパスキーを生成し、事前設定された ID 証明書を認証に使用します。
Web サイトは証明書を検証し、デバイス証明書が組織の CA にリンクされているかどうかを確認します。

証明書利用者は、どの CA 証明書を信頼すべきかを知る必要があります。組織管理者は、CA 証明書のコピーを証明書利用者にアップロードできます (12:38)。

WebAuthn パック構成証明の形式

証明書利用者は、Web 認証パスキー作成応答 (13:12) 内の認証要求を確認する必要があります。

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
            <…>
        },
        <…>
    },
    <…>
}

キーポイント:

最初に確認してくださいaaguidApple デバイスの価値と一致するかどうか -alg: -7ES256 アルゴリズムの使用を示します -sig認証済みの署名です -x5cそれぞれ X.509 形式の認証証明書と証明書チェーンを含む配列

詳細

導入プロセスの構成

ステップ 1: MDM サーバーの構成

MDM サーバーは次のステートメントをデバイスに送信します。

パスキー構成証明の構成: 証明書利用者と参照される ID 資産を指定します
アイデンティティ資産: エンタープライズ CA から証明書を取得するために必要な情報が含まれています

ステップ 2: デバイスのアクティベーション

デバイスがステートメントを受信した後、次のようになります。

設定を解析するAttestationIdentityAssetReference- エンタープライズ CA サーバーに ID 証明書を要求します。
証明書をキーチェーンに保存

ステップ 3: ユーザーが Web サイトにアクセスします

ユーザーがアクセスするとRelyingPartiesWeb サイトが次の場所に掲載されている場合:

Web サイトは WebAuthn API を呼び出してパスキーの作成を要求します
デバイスはエンタープライズ認証が必要であることを検出します
プロビジョニングされた証明書を使用して、新しく生成されたパスキーを認証します
認証オブジェクトを Web サイトに返す

ステップ 4: 依拠当事者の検証

ウェブサイト検証認証:

チェックaaguidApple デバイスからの送信を確認する
証明書チェーンが組織の CA にリンクされていることを確認します。
管理対象デバイスにパスキーが作成されたことを確認します
パスキーの登録を受け入れるか拒否する

ユーザーエクスペリエンス

Tailscale を例に挙げます (14:37):

ユーザーがパスキー名を選択します 2.「パスキーを作成して参加」をクリックします。
パスキーは管理対象 Apple ID の iCloud キーチェーンに保存されます 4.「続行」をクリックしてFace IDによるログインを完了します。

ユーザーが個人のデバイスでパスキーを作成しようとすると、「デバイスは組織によって管理されていません」というエラーが表示されます。これは、パスキー認証によって実現されます。

再度ログインするのは簡単です。「パスキーでサインイン」をクリックし、以前に使用したパスキーを選択し、Face ID で確認します。

重要ポイント

内部ツール Web サイトのパスキーログインを有効にする

対処方法: 社内 Wiki、ダッシュボード、CI システム、その他のツールのログイン方法をパスワードからパスキーに変更します。
価値がある理由: 内部ツールのパスワードポリシーは緩いことが多く、フィッシング攻撃の標的となる価値の高いものです。パスキーによりパスワードが盗まれるリスクが排除されます
開始方法: WebAuthn をサポートするサーバーにパスキーの登録と認証プロセスを実装し、フロントエンドを呼び出します。navigator.credentials.create()そしてnavigator.credentials.get()

管理対象 Apple ID を使用して従業員の認証情報を一元管理

やるべきこと: 従業員用の管理対象 Apple ID を作成し、iCloud キーチェーンをオンにして、管理対象デバイスの同期のみを設定します。
価値がある理由: 仕事用のパスキーが従業員の個人用デバイスに同期されないようにし、資格情報漏洩のリスクを軽減します。
開始方法: Apple Business Manager で管理対象 Apple ID を作成し、アクセス管理制御を「管理対象デバイスのみ」に設定します

SaaS 統合のためのエンタープライズパスキー認証

対処方法: 企業の SaaS プロバイダー (Slack、Notion など) がエンタープライズパスキー認証をサポートし、管理対象デバイスへの登録を制限できるようにします。
価値がある理由: MDM の認証構成と SaaS の WebAuthn サポートを組み合わせることで、従業員は企業デバイスを使用してのみ重要なサービスにアクセスできるようになります
開始方法: SaaS プロバイダーにエンタープライズ CA 証明書を提供し、エンタープライズ証明書を持つパスキーのみを受け入れるように証明書利用者を構成します。

SMS 2FA の段階的廃止

対処方法: パスキーを展開した後、アカウントの SMS および TOTP の 2 要素認証を段階的に廃止します。
実行する価値がある理由: SMS と TOTP はどちらもフィッシングの可能性があります。パスキー自体は多要素認証 (デバイス + 生体認証) です。脆弱な 2 番目の要素を追加すると、攻撃対象領域が増加します。
開始方法: まず、リスクの高いアカウント (管理者、財務) でパスキーをテストし、証明書利用者のサポートを確認した後、これらのアカウントの SMS 2FA をオフにします。