패스키: 기업에서 사용할 준비가 되셨나요?

이 블로그는 2024년에 처음 게시되었으며 업데이트되었습니다. 

구글, 애플, 페이스북, 메타 등 다양한 소비자 서비스 덕분에 패스키의 사용이 점점 더 보편화되고 있습니다. 패스키를 사용하면 기존의 비밀번호 기반 로그인이나 비밀번호 없는 다단계 인증(MFA)에 비해 보안성이 크게 향상됩니다.

이메일에 이모티콘 반응을 보낼 수 있는 것처럼 일부 소비자 솔루션이 업무용으로 확장되는 경우가 종종 있습니다. 하지만 인스타그램에서 패스키를 사용하여 로그인할 수 있다고 해서 기업에서도 그렇게 해야 할까요?

간단히 말해, 패스키를 기업에서 사용할 준비가 되었나요?

그리고 FIDO 얼라이언스 는 2013년 여러 기업이 두 번째 요소로 사용할 인증 표준을 개발하기 위해 설립한 단체로, 오늘날 FIDO는 강력한 비밀번호 없는 인증 수단으로 사용되고 있습니다.

2013년 이후, FIDO는 그 이름을 구성하는 약어 그대로 ‘온라인에서 신속한 신원 확인(Fast Identity Online)’을 실현한다는 점에서 가장 인기 있는 비밀번호 없는 로그인 방식 중 하나로 자리 잡았습니다. FIDO 연합은 소비자 환경에 중점을 두고 있습니다. 당연히 이 연합의 주요 회원사인 애플, 구글, 페이팔, Microsoft가 이 분야에서 활발히 활동하고 있습니다. RSA는 FIDO 얼라이언스의 회원입니다. 또한 기업 도입 실무 그룹의 공동 의장을 맡고 있습니다.

FIDO 자격 증명은 비대칭 키 쌍을 사용하여 서비스에 인증합니다. FIDO 자격 증명이 서비스에 등록되면 FIDO 인증자에 새 키 쌍이 생성되고 서비스는 해당 키 쌍과 해당 키 쌍만을 신뢰합니다. 키 쌍은 서비스의 정확한 도메인 이름에 연결됩니다.

서비스와 FIDO 인증 정보 간의 이러한 엄격한 일대일 대응 관계가 바로 높은 수준의 피싱 저항성을 만들어 냅니다. 사용자가 실제 사이트를 위해 생성된 패스키를 사용하여 가짜 피싱 사이트에 로그인하려고 시도하더라도, 지정된 도메인 이름이 인증 정보와 일치하지 않기 때문에 로그인에 실패하게 됩니다.

2022년에 애플, 구글, 마이크로소프트는 새로운 유형의 FIDO 자격 증명에 대한 지원을 시작했습니다. 패스키. 2023년에 FIDO 얼라이언스는 "패스키"를 모든 유형의 FIDO 자격 증명에 사용할 수 있으므로 조직에서 "패스키"를 언급할 때 정확히 무엇을 의미하는지 혼동할 가능성이 있습니다.

이러한 모호성은 FIDO 얼라이언스에서 해결했지만(아래 참조), 여전히 조직에 존재할 수 있습니다. 모든 패스키가 동일하게 만들어지거나 기업에서 사용하기에 적합한 것은 아니므로 이러한 모호성을 해결하는 것이 중요합니다.

패스키 유형

이제 FIDO 얼라이언스에서 정의한 대로 장치 바인딩형과 동기화형 두 가지 유형의 패스키가 있습니다.

디바이스 바인딩 패스키와 동기화된 패스키 비교

기기 기반 패스키(passkey)는 일반적으로 특정 “보안 키” 기기에 저장됩니다. 이 유형의 패스키는 개인 키가 기기 밖으로 절대 유출되지 않아 추출이나 원격 침해를 방지할 수 있기 때문에, 일반적으로 더 안전한 것으로 간주됩니다.

그러나 이는 또한 기기를 분실하거나 파손된 경우, 사용자가 새 기기에 새로운 패스키를 등록해야 함을 의미합니다. 기기에 바인딩된 패키는 특히 보안 수준이 높은 환경이나 기업용 사례에서 선호되며, 보안 키나 TPM(Trusted Platform Module)과 같은 하드웨어를 활용하는 경우가 많습니다.

이제 iOS 및 Android용 RSA Authenticator 앱과 같은 특정 모바일 애플리케이션에서도 기기 연동 패스키가 지원됩니다.

동기화된 암호 키

동기화된 패스키의 경우, 키 자료는 이른바 ‘원격 동기화 구조’를 통해 저장되며, 이후 동일한 사용자가 소유한 다른 기기에서 이 키 자료를 복원할 수 있습니다. 현재 주요 동기화 인프라로는 Microsoft, Google, Apple이 있습니다. 즉, 안드로이드 폰을 패스키로 등록하면 해당 키 자료가 Google에 저장되며, 그 결과 다른 모든 안드로이드 기기에서도 곧바로 사용할 수 있게 됩니다.

동기화된 비밀번호는 WhatsApp이나 Facebook과 같이 널리 사용되는 서비스를 지원하는 것 외에도 일반적인 비밀번호 사용이 급격히 증가한 주된 이유입니다. 많은 계정과 많은 디바이스를 가진 한 명의 사용자가 모든 디바이스에서 동일한 동기화된 비밀번호를 사용할 수 있기 때문입니다.

패스키(Passkey)는 기존의 비밀번호를 암호학적 키 쌍으로 대체하여, 강력하고 피싱 공격에 강한 인증 방식을 제공합니다. 사용자가 서비스에 가입하면, 사용자의 기기에서 고유한 개인 키-공개 키 쌍이 생성됩니다. 개인 키는 사용자의 기기에 안전하게 저장되는 반면, 공개 키는 서비스 측과 공유됩니다. 인증 과정에서 기기는 서비스 측에서 보낸 챌린지에 서명함으로써 개인 키를 보유하고 있음을 증명하며, 이 서명은 저장된 공개 키를 사용하여 검증됩니다. 공유된 비밀 정보가 전송되지 않고, 비밀번호가 생성되거나 저장되지 않으므로, 인증 정보 도용이나 리플레이 공격의 위험이 획기적으로 줄어듭니다.

기존 비밀번호는 추측, 도용 또는 피싱될 수 있는 공유 비밀에 의존하기 때문에 공격자들이 흔히 사용하는 진입 지점입니다. 이러한 비밀번호는 여러 계정에서 재사용되는 경우가 많고, 안전하지 않게 저장되며, 무차별 대입 공격이나 크리덴셜 스터핑 공격에 취약합니다.

패스키(Passkey)는 비밀번호를 공개-개인 키 암호화 방식으로 대체함으로써 이러한 위험을 제거합니다. 인증은 해당 키를 전송하지 않고도 키의 소유권을 증명함으로써 이루어집니다. 이러한 접근 방식은 피싱, 인증 정보 도용, 비밀번호 재사용 등 가장 흔한 공격 경로를 무력화합니다. 조직의 경우, 패스키를 도입하면 보안 인증 수준이 획기적으로 향상될 뿐만 아니라, 비밀번호 재설정 및 지원 요청으로 인한 부담도 줄일 수 있습니다.

• 피싱 방지: 패스키는 기존의 피싱 공격을 방지하도록 설계되었습니다. 비밀번호가 포함되어 있지 않기 때문에 도용하거나 재사용할 수 없습니다.
• 빠르고 편리함: 패스키를 사용하여 로그인하는 것은 생체 인식(예: Face ID 또는 지문)을 사용하는 것만큼이나 간단하여 사용자의 경험을 더욱 원활하게 만들어 줍니다.
• 익숙한 사용자 경험: 패스키 로그인은 일반적인 모바일 인증 패턴과 유사하므로 학습 곡선이 거의 또는 전혀 없습니다.
• 도메인 매칭 보안: 패스키는 키 자료가 원래 서비스 도메인에서만 작동하도록 하여 추가적인 보호 계층을 제공하며, 이는 모든 MFA 방식이 제공하지 않는 이점입니다.
• 정부 승인: 미국에서는 피싱 방지가 연방 정부의 주요 의무 사항입니다. 행정 명령 14028 중요한 인프라를 보호하기 위해 비밀번호가 필요 없는 피싱 방지 인증이 필요합니다.

패스키는 상당한 이점을 제공하지만 몇 가지 중요한 과제와 문제점도 있습니다.

• 사용자 경험: 예를 들어, 보안 키를 USB 포트에 삽입하거나 PIN을 입력하라는 요청과 같은 패스키 관련 안내 메시지는 운영 체제와 브라우저에 따라 다르게 표시됩니다. 이러한 안내 메시지들로 인해 사용자 교육이 더 어려워지고 지원 문의가 늘어날 가능성이 높습니다.
• 다른 공격으로부터의 주의 분산: 패스키를 사용한다고 해서 사회공학 공격과 같은 다단계 인증(MFA) 우회 공격으로부터 갑자기 안전해진다고 생각하는 사람은 큰 오해를 하고 있는 것입니다. 패스키가 도움이 되는 사회공학 공격 유형은 피싱뿐입니다. 안타깝게도 그 외에도 다양한 변종이 존재합니다. 라스베이거스의 MGM 리조트나 시저스 팰리스를 대상으로 한 공격에는 사회공학 요소가 포함되어 있었는데, 바로 헬프데스크를 악용해 공격자가 직접 다단계 인증(MFA) 인증기를 등록할 수 있도록 한 것이었습니다.
• 기기 분실 또는 기기 교체 시 발생하는 문제: 사용자가 기기 연동 패스키를 지원하는 기기에 더 이상 접근할 수 없게 되면, 해당 패스키는 복구할 수 없습니다.
• 모든 서비스에 걸쳐 제한적인 지원: 패스키의 보급이 확대되고 있지만, 아직 모든 웹사이트나 기업용 시스템이 이를 지원하는 것은 아니기 때문에 일상적인 사용에 제약이 따를 수 있습니다.
• 사용자의 혼란 또는 인식 부족: 패스키라는 개념은 여전히 많은 사용자에게 생소하기 때문에, 설정이나 동기화 과정, 혹은 내부적으로 어떤 일이 일어나는지 등에 대해 혼란을 야기할 수 있습니다. 용어의 다양성(패스키, 보안 키, FIDO 키)과 업계 전반에 걸쳐 진화하는 표준은 이러한 혼란을 가중시켜, 사용자와 조직이 모범 사례를 명확히 이해하고 패스키를 일관되게 구현 및 도입하는 데 어려움을 겪게 할 수 있습니다. 이는 또한 설정 및 사용 중 실수로 이어지고, 지원 문의가 증가하며, 잠재적인 보안 취약점을 초래할 수도 있습니다.
• 인프라 준비 상태: 패스키를 도입하려면, 특히 기존 인증 방식을 대체하는 경우, 조직은 신원 관리 플랫폼, 기기 관리 정책 및 교육 프로그램을 업데이트해야 할 수 있습니다. 조직은 웹 전용 인증 방식 때문에 기존 또는 온프레미스 리소스가 패스키와 호환되지 않을 수 있음을 알게 될 수도 있습니다. 이러한 경우, 조직은 다음을 통해 다단계 인증(MFA)을 현대화해야 합니다. 비밀번호 없는 다양한 환경을 아우르며 레거시 인프라를 유지할 수 있는 기능.

다양한 브라우저, 디바이스, 운영 체제에서 일관된 워크플로우를 제공하는 데 있어 오늘날의 패스키가 직면한 문제를 고려할 때, 업계가 진정으로 원활한 크로스 플랫폼 경험을 보장하기 위해 무엇을 할 수 있을까요? 사용자를 혼란스럽게 하고 광범위한 채택을 지연시킬 수 있는 불일치를 해결하기 위한 최선의 방법을 어떻게 결정할 수 있을까요?

RSA의 UX 리더십은 일관된 사용자 경험을 옹호하기 위해 FIDO 얼라이언스의 실무 그룹에 적극적으로 참여하고 있습니다. 인사이트를 제공함으로써 최종 사용자에게 방해 요소를 줄이고 마찰을 줄이며 통일성을 높일 수 있는 표준을 만드는 데 기여하고자 합니다.

모빌리티는 여러 환경에서 원활한 패스키 환경을 구축하는 또 다른 측면입니다. 직원들은 점점 더 모바일 우선 워크플로우의 편리함을 기대하고 있습니다. 스마트폰에서 회사 리소스에 액세스하는 것이 같은 기기의 잠금을 해제하는 것처럼 직관적으로 느껴진다면, 패스키와 같은 새로운 인증 방법을 훨씬 더 쉽게 채택할 수 있습니다. 마찰 없는 모바일 환경은 사용자의 거부감을 없애고 학습 곡선을 최소화하며 비밀번호에서 훨씬 더 원활하게 전환할 수 있도록 도와줍니다. 친숙하고 권한에 대해 투명하며 사용자의 디바이스나 플랫폼에 관계없이 일관된 인터페이스를 제공함으로써 조직은 혼란을 줄이고 신뢰를 향상시킬 수 있습니다. RSA 모바일 FIDO 솔루션은 디바이스에 구애받지 않는 방식으로 패스키를 구현하는 방법의 예시입니다.

모바일 인증이 허용되지 않는 보안 시설 및 고신뢰성 환경에서는 RSA iShield Key 2 시리즈 피싱 공격에 강하고 플랫폼 간 호환되는 비밀번호 없는 보안을 제공하는 FIPS 140-3 레벨 3, FIDO2 인증 하드웨어 인증기를 제공합니다.

망치만 있으면 모든 것이 못처럼 보인다는 말이 있습니다. 아무리 훌륭한 솔루션이라도 원래 소비자용이었던 솔루션을 기업용 애플리케이션으로 전환하는 것은 상당한 위험을 초래할 수 있습니다.

이 글을 읽는 동안 "동기화 패브릭"이라는 단어가 언급되는 순간 아찔한 기분이 들었을 수도 있습니다. 여러분의 직감이 맞았습니다.

사용자가 Apple이나 Google을 통해 로그인한 모든 기기에서 동기화된 패스키가 마치 마법처럼 나타나는 사실은 기업 환경에서 큰 위험 신호이며, 다음과 같은 중대한 의문을 제기해야 합니다:

• 사용자가 인증에 여러 대의 디바이스(사적으로 사용하는 디바이스도 가능)를 사용할 수 있도록 허용해야 하나요? 그렇다면... 몇 개나 허용할까요?
• 동기화된 비밀번호를 사용하면 Google 또는 Apple의 계정 복구 프로세스를 통해 "분실된" 비밀번호를 복원할 수 있습니다. 하지만 이러한 프로세스가 충분히 안전할까요?
• 사용자가 친구나 가족과 패스키를 공유할 수 있는 Apple 기능은 꽤 좋은데, 기업용 애플리케이션에 로그인하는 데 사용되는 패스키에도 적용되나요?

동기화된 암호키를 사용하면 회사의 보안이 갑자기 Apple과 Google의 기술 및 조직 보안에 크게 좌우됩니다. 물론, 어쨌든 다음과 같은 사용으로 인해 어느 정도 의존성이 있습니다. iOS 및 Android-하지만 동기화된 패스키는 이 종속성을 상당히 증가시킵니다.

이것은 이론적인 취약점도 아닙니다. Retool 는 위협 행위자가 이 기능을 사용하여 시스템에 액세스하는 방법에 대해 설명하면서 이 기능이 “Google 계정이 손상되면 이제 MFA 코드도 손상된다”는 것을 의미한다고 지적했습니다.”

회사에서 패스키를 사용해야 하는지 여부는 일반적인 방법으로 답할 수 없습니다. 조직마다 상황이 다르기 때문에 고유한 보안과 운영 우선순위의 균형을 맞춰야 합니다.

또한, 패스키 사용 여부는 예/아니오의 문제가 되어서는 안 됩니다. 일반적으로 패스키 또는 비밀번호 없는 로그인의 도입은 조직의 전체 MFA 프로세스를 근본적으로 검토하는 데 사용되어야 합니다. 15년 동안 하드웨어 OTP 토큰에 적합했던 방식이 오늘날에는 패스키나 다른 MFA 방식에 더 이상 적합하지 않을 수 있습니다.

RSA는 패스키가 조직의 전략과 부합하고, 조직이 다음 질문들에 대한 답변을 신중하게 검토한다면 기업 환경에서 도입될 수 있다고 믿습니다. 우리는 다음과 같은 상황에서 조직들이 패스키를 성공적으로 활용하는 사례를 목격해 왔습니다. RSA^® ID Plus, 는 비밀번호가 필요 없는 다양한 옵션을 제공하는 종합적인 ID 및 액세스 관리(IAM) 플랫폼입니다.

저희는 보안을 최우선으로 하는 조직이며 설계 시 보안/기본값 보안 원칙을 사용하기 때문에 기본적으로 동기화된 패스키를 사용하지 않습니다. RSA 환경에서는 기본적으로 디바이스 바인딩된 패스키만 사용할 수 있어 관리자의 추가 작업 없이도 최대한의 보안 수준을 바로 사용할 수 있습니다.

조직은 패스키 도입 여부를 평가할 때 다음과 같은 질문을 해야 합니다. 인증자는 어떻게 등록되어 있는가? "인증자를 분실했을 때" 시나리오를 안전하게 처리할 수 있는 프로세스가 있는가? 사용자, 애플리케이션 및 데이터의 분류는 어떻게 되어 있나요?

패스키는 다음과 같습니다. MFA 방법 수많은 사례 중 하나입니다. 네, 피싱 방지 기능은 훌륭하지만, 사용자들이 이 기능을 사용해 접근해야 하는 모든 보호 대상 리소스에 로그인할 수 있을까요?.

이러한 이유와 기타 여러 가지 이유로 MFA 시스템은 기술적으로 최신 상태일 뿐만 아니라 QR코드, 생체인식, OTP, 푸시 메시지, 패스키 등 다양한 MFA 방법을 지원하는 것이 중요합니다.

MFA 관련 프로세스를 새로운 위협에 맞게 조정하는 것도 중요합니다. 헬프 데스크도 소셜 엔지니어링 공격으로부터 안전한가요?

패스키가 이해가 되신다면 저희가 도와드리겠습니다. 문의하기 자세히 알아보거나 시작하려면 ID Plus 45일 무료 체험판.

패스키 도입을 결정하는 것은 쉬운 일입니다. 이 가이드에서는 성공적인 도입을 위한 세 단계, 즉 평가, 시범 운영, 전사적 도입을 다루며, 이미 이 과정을 거친 조직들의 실제 사례를 소개합니다. RSA의 비밀번호 없는 인증 기능에 대한 전체 개요를 보려면 다음을 방문하십시오. RSA 비밀번호 없는 솔루션 페이지.

1단계: 평가 및 계획 수립 (4~8주)

1. 인증 감사를 실시하십시오. 인증이 필요하거나 인증과 관련된 모든 애플리케이션, 인프라 및 시스템을 파악하고, 아직 FIDO2를 지원하지 않는 항목을 확인하십시오.
2. 고위험 사용자 그룹을 파악하십시오. 특권 관리자, 재무 담당자, 재택 근무자, 공유 기기 사용자는 각각 다른 접근 방식이 필요하므로, 배포를 계획하기 전에 위험 수준에 따라 직원을 분류하십시오.
3. 패스키 정책을 정의하십시오. 어떤 사용자 그룹이 기기 연동형 패스키, 동기화형 패스키 또는 이 둘을 혼합하여 사용해야 할지 결정하십시오. RSA는 기기 연동형 패스키를 기본값으로 설정하고, 동기화형 패스키는 그 장단점을 고려했을 때 타당하다고 판단되는 경우에만 사용하도록 권장합니다.
4. USB 포트, BLE 또는 모바일 기기 사용 제한 등 패스키 사용에 영향을 미칠 수 있는 내부 정책을 검토하십시오. 단계별 배포 일정을 수립하십시오. 주요 단계를 설정하고, 담당자를 지정하며, 진행/중단 기준을 정의하십시오. 조기에 경영진의 동의를 얻으십시오.

2단계: 시범 운영 (6~10주)

1. 시범 운영 그룹을 신중하게 선정하십시오. IT 및 보안 담당자가 이상적인 초기 사용자입니다. 소수의 임원 비서들을 포함시키면 공유 컴퓨터나 업무 위임과 같은 실제적인 특수 사례를 파악하는 데 도움이 됩니다.
2. 사용 사례에 따라 해당 환경에서 두 가지 패스키 유형을 모두 테스트하십시오. 조직에서 사용하는 다양한 기기 유형과 운영 체제 전반에 걸쳐 등록, 로그인, 기기 절전 모드 해제 후 재인증, SSO 기능을 검증하십시오.
3. 헬프데스크 절차를 수립하고 테스트하십시오. 기기 분실, PIN 번호 분실, 신규 입사자 온보딩 및 퇴사자 오프보딩과 같은 시나리오가 실제 운영 환경에서 발생하기 전에 미리 시뮬레이션해 보십시오. 헬프데스크 직원은 사회공학적 공격에 취약해지지 않으면서도 복구 워크플로를 안전하게 수행할 수 있어야 합니다.
4. 성공 지표를 정의하십시오. 확장하기 전에 등록률, 인증 성공/실패율, 헬프데스크 문의 건수를 기준치로 추적하십시오.
5. 체계적인 피드백을 수집하세요. 시범 사용자를 대상으로 2주 및 6주 차에 설문조사를 실시하세요. 수집한 결과를 바탕으로 본격적인 확대 시행에 앞서 교육 자료와 설정을 업데이트하세요.

3단계: 기업 내 도입 (2~6개월)

1. 변화 관리 프로그램을 시작하세요. 긴 문서보다 짧은 동영상 안내 영상과 서면 업무 지원 자료가 더 효과적입니다. 사용자 그룹별로 콘텐츠를 맞춤화하세요. 원격 근무 개발자의 경험은 공동 작업 공간을 사용하는 사용자의 경험과는 다르기 때문입니다.
2. 단계적으로 도입하십시오. 부서, 지역 또는 위험 등급별로 배포하십시오. 일반적으로 고위험 사용자를 먼저 처리하고, 기기를 공유하거나 구형 시스템에 의존하는 사용자는 마지막에 처리합니다.
3. 예비 인증 수단을 항상 확보해 두십시오. 기존 다단계 인증(MFA) 방식을 즉시 제거하지 마십시오. 등록 건수가 목표 기준치(일반적으로 부서당 90%+)에 도달할 때까지 OTP 푸시 알림, QR 코드 또는 하드웨어 토큰을 대체 수단으로 유지하십시오.
4. 도입 현황 및 인증 상태를 모니터링합니다. 플랫폼 대시보드를 활용하여 등록 완료 현황, 실패율, 헬프데스크 동향을 추적합니다. 이상 징후가 발생하면 조기에 알림이 발령되도록 설정합니다.
5. 보안 조치를 통해 모든 과정을 마무리하세요. 전체 배포가 완료된 후, MFA 정책 문서를 업데이트하고 배포 후 검토를 실시하십시오. 패스키를 사용하면 자격 증명 피싱을 방지할 수 있지만, 헬프데스크에서 발생하는 사회공학적 공격은 여전히 실질적인 위험 요소로 남아 있습니다.

다음은 일반적인 배포 패턴을 바탕으로 한 예시입니다.

시나리오 1: 금융 서비스 — 지역 은행, 직원 5,000명
한 중형 지역 은행은 다음을 통해 기기 전용 패스키를 도입했습니다. RSA ID Plus ~와 함께 FIPS 140-3 인증을 받은 하드웨어 보안 키 권한이 있는 사용자와 지점 직원을 대상으로 합니다.

• 주요 과제: 기존 텔러 애플리케이션에는 FIDO2 프록시 계층이 필요했으며, 헬프데스크 직원들은 시스템 도입 전에 사회공학 공격 대응 교육을 받아야 했다.
• 패스키 유형: 기기에 고정된 하드웨어 보안 키
• 연표: 6개월
• 결과: 43% 헬프데스크 티켓 감소; 배포 후 비밀번호 관련 보안 침해 사례 제로

시나리오 2: 정부 — 연방 기관, 직원 12,000명
한 민간 연방 기관은 에어갭이 적용된 기밀 네트워크 구역을 포함하는 하이브리드 환경 전반에 걸쳐 행정명령 14028호 및 OMB M-22-09의 피싱 방지 다단계 인증(MFA) 의무 사항을 준수해야 했습니다.

• 주요 과제: 에어갭(Air-gap) 구역에는 인터넷 연결 없이 인증할 수 있는 방식이 필요했고, 구형 사건 관리 시스템에는 FIDO2 프록시 계층이 필요했으며, 30개 이상의 현장 사무소에는 원격 등록 지원이 필요했습니다.
• 패스키 유형: FIPS 140-3 레벨 3 RSA iShield Key 2 전 직원 대상; 에어갭이 적용된 세그먼트용 RSA DS100 OTP 토큰
• 연표: 10개월
• 결과: 행정명령 14028호 및 M-22-09 지침 준수 인증 완료; 자격 증명 수집률이 18%에서 1% 미만으로 감소; 헬프데스크 티켓 38% 감소