스트리밍은 대부분의 브라우저와
Developer 앱에서 사용할 수 있습니다.
-
기업에 패스키 적용하기
기업의 관리형 환경에서 패스키의 이점을 경험해 보세요. 기업 환경에서 관리형 Apple ID의 iCloud 키체인 지원을 통해 패스키가 잘 작동할 수 있는 방법을 탐구해 봅니다. 또한 관리자가 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
-
다운로드
♪ ♪
안녕하세요 저는 Alex Sokolov예요 인증 환경 팀의 엔지니어링 관리자죠 오늘은 회사에서 패스키를 배포하는 방법을 다룰게요 먼저 패스키의 내용을 되짚어 보고 회사에서 특히 중요한 이유를 다룬 뒤 관리형 환경에서의 독특한 요건을 충족하기 위해 여러분이 사용할 수 있는 새로운 도구에 관해 얘기할게요
패스키는 비밀번호를 대체해요 더 빠르고 쉽게 로그인할 수 있죠 Touch ID나 Face ID로 인증하면 끝나요 패스키가 훨씬 안전한 이유는 앱과 웹 사이트에 맞춰 강력하고 독특하여 피싱 공격에도 끄떡없기 때문이죠 iOS, iPadOS와 macOS에 구축된 비밀번호 관리자를 사용하여 패스키를 저장하면 iCloud 키체인을 사용하여 Apple 기기에 안전하게 동기화되어 즉시 사용할 수 있어요 패스키가 소문자인 이유는 '비밀번호'라는 단어처럼 일반 명사이기 때문이고 FIDO Alliance와 구글, 마이크로소프트 등이 사용하는 업계 표준 용어죠 패스키의 원리를 빠르게 되짚어 보고 싶다면 WWDC22의 '패스키를 만나다' 세션을 먼저 시청하세요 패스키를 도입했을 때 패스키가 비밀번호보다 나은 이유를 자세히 알았으니 오늘은 패스키로 직원 계정을 독특하게 보호하여 해커들의 일반적인 공격을 회사에서 막는 방법을 다룰게요 요즘 기업에서 제일 걱정해야 하는 세 가지는 피싱 공격과 자격 증명 도용 공격 그리고 이중 인증 우회 공격이에요 하나씩 살펴보죠 직원들에 대한 피싱 공격은 기업이 온종일 방어해야 하는 가장 흔한 공격 중 하나예요 대규모 해킹에서 공격자들이 초기 발판으로 삼는 공격이죠 2022 Verizon 데이터 유출 조사 보고서에서 1억 건이 넘는 피싱 시도를 살펴봤는데 직원의 2.9%가 피싱 링크를 클릭하며 이 비율이 장기간 일정하게 유지됐다고 해요 이 정도의 비율이면 범죄자들이 계속할 유인이 있죠 기업의 규모가 커질수록 이 문제는 심각해져요 직원이 100명인 회사에서는 3명이 피싱 링크를 클릭하겠지만 500명인 회사에서는 15명이 되고 1,000명인 회사에서는 29명이 되죠 이 정도 숫자면 괜찮다고 생각할 수 있지만 1, 2개의 계정만 피싱 공격에 성공해도 전면적인 유출의 초기 진입점이 될 수 있어요 사용자가 뭔가 타이핑할 때마다 이상한 곳에 타이핑하도록 속일 수 있죠 패스키에서는 타이핑을 할 일이 없어요 각 패스키는 사용되는 웹 사이트나 앱에 본질적으로 연결돼 있어서 사용자들이 가짜 웹 사이트에서 패스키를 사용하도록 속일 수 없죠 패스키가 있으면 자격 증명 피싱이 사라져요 매주 서버 유출에 관한 새로운 기사를 보면 해커들이 서버에서 사용자의 비밀번호를 훔쳤다고 하죠 2022년 유출의 40%가 도용된 자격 증명을 사용했는데 같은 보고서에서 거의 4,000건의 유출을 분석한 결과예요 비밀번호를 사용하면 서버에 해시를 저장하는데 해시는 도난당할 수 있으며 크랙의 가능성이 있어 텍스트로 된 비밀번호가 해커에게 공개되죠 그리고 A 유출에서 얻은 비밀번호를 사용하여 B나 C 서비스에서도 로그인을 시도할 수 있어요 서버 유출과 자격 증명 공격이 연쇄적으로 일어날 수 있죠 패스키는 이런 구조를 깨요 서버에 저장된 건 공개키밖에 없으니까요 패스키를 사용하면 서버에서 훔칠 만한 게 없죠 보안 요소를 늘리는 게 방법이라고 생각할 수도 있지만 이중 인증은 사람들이 생각하는 것처럼 안전하지 않아요 공격자들이 사용자를 속여 3가지 이중 인증을 우회하는 공격이 증가하고 있죠 SMS 코드는 비밀번호처럼 쉽게 피싱할 수 있어요 시간제 OTP도 같은 방법으로 피싱할 수 있죠 푸시 알림은 피싱할 수 없지만 푸시 피로 공격의 대상이 될 수 있어요 최근 공격도 이중 인증의 취약성을 이용했죠 해커가 직원에게 계속 푸시 알림을 보내서 그중 하나를 확인하도록 속인 거예요 비밀번호에 추가 인증 요소를 도입했던 건 이미 여러 면에서 취약했기 때문이었어요 패스키는 임시방편이 아니죠 취약한 주요 요소를 구조적으로 안전한 새로운 주요 요소로 대체해요 패스키를 사용하면 주요 요소가 취약하지 않죠 SMS, TOTP, 푸시 알림과 같이 취약한 이중 요소를 도입하면 패스키로 보호하는 계정을 더 안전하게 해 주지 않아요 패스키의 보안 이점이 마음에 들지만 훌륭한 보안에 따르는 번거로움이 걱정될 수도 있죠 보안성과 사용성 중 하나를 포기했던 것에 익숙할 거예요 새로운 비밀번호를 생성하는 것과 새로운 패스키를 생성하는 경험을 나란히 비교해 보죠 보는 것처럼 패스키 생성이 비밀번호를 만드는 것보다 훨씬 빠르고 쉬워요 Face ID 하나면 끝나죠 이제 생성을 비교했으니 재로그인 경험을 비교해 보죠 비밀번호를 쓰면 사용자가 기억하고 입력해야 해요 패스키를 쓰면 Face ID 하나로 끝나죠 비밀번호 관리자가 경험을 개선할 수 있지만 최고의 비밀번호 관리자도 패스키의 사용자 경험과 비교할 수 없어요 지금까지 보안과 사용자 경험 사이에서 선택하는 것에 익숙했지만 패스키가 놀라운 업적을 이뤘죠 훌륭한 보안과 훌륭한 사용자 경험을 갖췄어요 지금까지 많은 내용을 다뤘으니 기업을 위한 패스키의 독특한 이점을 되짚어 보죠 피싱이 없어요 직원들을 보호하는 비밀번호나 많이 사용하는 이중 인증은 피싱이 가능해요 패스키는 피싱이 불가능하죠 서버에서 자격 증명을 도난당하지 않아요 비밀번호 해시는 서버 유출 때 도난당할 수 있죠 패스키를 사용하면 서버에 훔칠 만한 게 없어요 공개키만 저장하기 때문이죠 그리고 사용자 경험이 훌륭해요 비밀번호를 사용하면 비밀번호를 복잡하게 설정하고 주기적으로 바꿔야 하죠 패스키는 Face ID나 Touch ID만 사용하면 끝이에요 패스키는 장점밖에 없죠 더 안전한 자격 증명으로 회사의 계정을 보호하고 직원들이 좋아하는 사용자 경험을 제공해요 조직의 IT 관리자가 회사에서 패스키와 같은 경험을 제공하고 싶어 하지만 관리형 환경의 독특한 요건을 충족해야 하죠 이러한 요건을 얘기해 보고 어떻게 충족할지 알아볼게요 먼저 iCloud 키체인과 패스키를 사용하는 Apple ID 계정을 관리해야 하죠 그리고 관리형 기기에만 패스키를 동기화하고 직원들의 개인 기기는 동기화하지 않아야 해요 물론 회사에서 생성하는 패스키를 IT에서 관리하는 관리형 Apple ID와 관련된 iCloud 키체인에 저장해야 하며 개인 Apple ID를 저장하면 안 돼요 이렇게 하면 패스키를 iCloud 키체인에 저장하고 다른 곳에 저장되지 않죠 다음은 신뢰하는 집단에 패스키 생성이 관리형 기기에서 이루어진다는 걸 증명해야 해요 마지막으로 패스키 공유를 꺼야 하는데 직원들끼리 자격 증명을 공유하면 안 되기 때문이죠 이러한 요건을 충족할 수 있는 새로운 도구를 설명해 드릴게요 세 가지 주제를 다룰 건데 관리형 Apple ID를 사용하는 것과 패스키 동기화를 제어하는 것 그리고 관리형 기기에서 회사 패스키를 생성하는 거예요 관리형 Apple ID는 조직에서 소유하고 관리하며 Apple Business Manager 또는 Apple School Manager에서 만들죠 macOS Sonoma, iOS 17과 iPadOS 17에서 관리형 Apple ID가 iCloud 키체인을 지원해요 관리형 Apple ID를 사용하면 사용자들이 iCloud 키체인으로 모든 기기에서 패스키를 쓰고 여러분이 계정을 관리할 수 있죠 iCloud 키체인에 저장된 패스키는 공유가 안 돼요 관리형 Apple ID의 놀라운 개선 사항을 알고 싶다면 '관리형 Apple ID로 더 많은 작업하기'를 시청하세요 Apple ID를 관리하는 것에 더하여 IT 관리자들은 패스키가 동기화된 기기들을 제어하고 관리형 기기에만 허용해야 해요 Apple Business Manager와 Apple School Manager에 접근 제어 기능이 생겼죠 관리자가 사용할 수 있는 2개의 제어 항목이 있어요 첫 번째는 IT 관리자들이 관리형 Apple ID로 직원들이 로그인할 수 있는 기기를 지정하는 거죠 '모든 기기'는 기본값이며 '관리형 기기만 허용'은 높은 보안성을 제공하며 직원들이 기기를 회사에 가져올 때 사용할 수 있어요 '관리 감독형 기기만 허용'은 가장 높은 수준의 보안이며 직원들에게 기기를 제공하는 조직에서 사용할 수 있어요 IT 관리자는 iCloud 콘텐츠를 허용하는 기기를 제어할 수 있으며 이는 iCloud 키체인의 패스키를 포함하며 3개의 선택지는 동일하죠 모든 기기, 관리형 기기만 허용 관리 감독형 기기만 허용이에요 이러한 기능을 통해 IT 관리자가 회사에서 사용하는 패스키를 관리형 기기에만 동기화할 수 있죠 기기 관리 서버에서 이 기능을 지원해야 하며 Apple Business Essentials와 바로 연동하여 사용할 수 있어요 이제 IT 관리자들이 회사 기기의 패스키를 관리하여 특정 패스키가 회사 기기에만 남는 방법을 알아볼게요 여러분은 관리형 기기에서만 패스키 생성을 요구하고자 하죠 구체적으로 말하자면 관리형 Apple ID의 iCloud 키체인에 패스키를 저장하여 모든 기기에 패스키 동기화를 제공하고 관리형 기기에서의 패스키 생성을 신뢰 집단에 증명하고자 하죠 이는 선언적 기기 관리의 도움으로 가능해요 선언적 관리의 개선 사항을 배우고 싶다면 '선언적 기기 관리의 개선 사항 살펴보기' 세션을 시청하세요 지금은 패스키를 관리하는 새로운 설정에 집중하죠 선언적 기기 관리에 새로 추가된 기업 패스키 증명 설정을 이용하여 기기의 사용자가 설정에 명시된 사이트를 방문할 때 안전하게 패스키를 생성해요 설정에서 신원 자산을 참조하죠 연관된 신원을 사용하여 생성된 패스키에 표준적인 Web Authentication 증명을 수행해요 Web Authentication의 신뢰 집단은 이 증명을 확인한 뒤 관련 사이트의 접속을 허용하죠 다음의 몇 개 슬라이드에서 이 절차를 소개할게요 이 의미는 특정 패스키를 관리형 기기에서만 생성할 수 있도록 제한하는 거죠 조금 전에 얘기했던 동기화 기능과 함께 사용하면 패스키가 연동되는 기기도 제어할 수 있어요 이 기능은 iOS, iPadOS와 macOS에서 사용할 수 있어요 이것은 패스키 증명 설정의 예죠 신원 자산에 대한 참조를 서버에서 제공하며 선언 집합의 형태로 기기에 전송해요 설정을 활성화하면 자산이 해결되며 결과로 나오는 신원은 키체인에 저장돼요 RelyingParties 속성은 Web Authentication 패스키 증명에 신원이 사용되는 장소를 나타내요 조직에서 기기를 설정하는 방식을 살펴보죠 먼저 MDM 서버가 패스키 증명 설정과 신원 자산을 기기에 전송하여 활성화를 보장해요 활성화가 되면 기업 인증 권한 서버에서 신원 인증서가 권한 설정돼요 이후 시점에 사용자가 웹 사이트를 방문하면 웹 사이트에서 접속에 필요한 패스키를 요구하죠 신뢰 집단에서는 이제 기업 증명을 통해 생성된 새로운 패스키만 받아들이고 다른 패스키는 거부할 수 있어요 기기에서 새로운 패스키를 생성하고 권한 설정된 신원 인증서를 사용한다는 걸 증명한 뒤 웹 사이트에 돌려보내죠 웹 사이트는 증명을 확인할 때 Web Authentication 기업 증명 페이로드 내의 기기 인증서가 조직의 인증 권한 서버로 추적되는지 확인해요 이는 신뢰하는 집단에 이 조직에서 관리하는 기기에서 패스키가 생성되었음을 증명하는 거죠 이것이 가능하려면 신뢰하는 집단에서 조직의 어떤 CA 인증서를 믿을 수 있는지 알아야 해요 이는 여러 방법으로 가능하며 조직 관리자가 신뢰하는 집단에 CA 인증서의 사본을 업로드할 수도 있죠 신뢰 집단은 패스키 생성 시점에만 이 증명을 확인해요 이후에는 패스키를 해당 집단에서 사용할 수 있으며 추가 증명이 필요 없죠 이렇게 생성된 패스키는 관리형 Apple ID의 iCloud 키체인에 저장돼요 이건 하드웨어 증명이 아니죠 그 분야가 궁금하면 'Apple 기기 관리의 새로운 소식' 세션에서 관리형 기기 증명을 알아보세요 신뢰하는 집단에서는 Web Authentication의 패스키 생성 응답 안에 있는 증명서를 봐야 해요 먼저 AAGUID가 화면의 값과 일치하는지 확인하여 Apple 기기에서 왔는지 확인하세요 이후에는 세 가지 항목으로 구성된 압축 증명서를 살펴보세요 암호화 알고리즘을 식별하는 숫자가 있어요 Apple 플랫폼에서는 ES256이 -7로 맞춰져 있어야 하죠 그리고 증명 서명을 포함하는 바이트 스트링이 있어요 마지막으로 증명 인증서와 인증서 체인의 배열이 있는데 각각 X.509 포맷으로 인코딩되어 있죠 증명서에 관해 더 알고 싶으면 공식 Web Authentication 문서에서 확인할 수 있으며 'Web Authentication 압축 증명서'를 검색하면 돼요 새로운 선언적 기기 관리 패스키 증명으로 IT 관리자들이 회사를 위한 구체적인 증명 패스키를 생성하여 신뢰하는 집단에서 알아보고 믿을 수 있어요 또한, 이러한 패스키가 관리형 Apple ID와 관련된 iCloud 키체인에 저장되도록 해 주며 사용자의 개인 Apple ID에 저장되지 않죠 관리형 Apple ID가 iCloud 키체인을 지원하면서 Apple Business Manager와 Apple School Manager의 관리 기능 제어와 선언적 기기 관리 설정의 패스키를 관리하여 회사의 패스키에 필요한 모든 요건을 충족할 수 있어요 이제 실제로 이용되는 패스키를 살펴보죠 제 조직의 IT 관리자가 저를 초대하여 Tailscale의 네트워크를 함께 관리하기로 했어요 패스키로 로그인하는 게 얼마나 쉬운지 보죠 먼저 패스키의 이름을 선택하세요 그리고 '패스키 생성 및 합류'를 탭하세요 제 패스키가 관리형 Apple ID의 iCloud 키체인에 저장되어 다른 기기에서 사용할 수 있어요 마지막으로 '계속'을 탭하고 Face ID로 로그인하세요 이게 끝이에요 조직 네트워크를 관리할 수 있죠 참고로 제 조직은 관리형 기기에서 패스키 생성을 요구하므로 실수로 개인 핸드폰에서 생성하려고 했다면 조직에서 관리하는 기기가 아니라는 오류가 나타나요 패스키 증명을 사용하여 이룩한 결과죠 회사 핸드폰으로 돌아오면 쉽게 다시 로그인할 수 있죠 '패스키로 로그인하기' 버튼을 탭하면 보는 것처럼 제 핸드폰이 이 웹 사이트에서 사용했던 패스키를 기억하죠 '계속'을 눌러 Face ID로 로그인하세요
마치면서 회사에서 패스키를 배포하기 위해 사용할 수 있는 새로운 기능을 되짚어 보죠 관리형 Apple ID로 패스키를 사용하여 어떤 기기를 동기화할지 관리할 수 있으며 Web Authentication 기업 증명으로 패스키 생성을 제어할 수 있어요 패스키를 통해 여러분의 회사를 피싱과 자격 증명 도난 공격에서 보호해 주며 직원들에게는 훌륭한 사용자 경험을 제공할 수 있죠 여러분의 값진 피드백 덕분에 개선 사항을 적용했으며 앞으로도 여러분의 의견을 기다리고 있을게요 감사합니다 ♪ ♪
-
-
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 <…> } <…> } <…> }
-
-
찾고 계신 콘텐츠가 있나요? 위에 주제를 입력하고 원하는 내용을 바로 검색해 보세요.
쿼리를 제출하는 중에 오류가 발생했습니다. 인터넷 연결을 확인하고 다시 시도해 주세요.