패스키의 점진적 채택에 필요한 변화 관리
패스키 지원을 구현하는 전체 프로세스에는 신중한 변화 관리가 필요합니다. 프로세스를 시작할 때 이를 예 상하면 재작업이나 좌절감을 야기하는 장애물을 제거하는 데 도움이 될 수 있습니다. 즉, 팀은 변화를 관리할 수 있어야 합니다. 예를 들어 변화 관리 기능에는 부서 또는 분야 간에 존재할 수 있는 커뮤니케이션 사일로를 연결하고, 부서 또는 분야 간의 종속성을 이해하고 정의하는 데 도움을 주고, 부서 간 예산을 책정하고, 부서 간 협업을 수행하는 것이 포함됩니다.
조직의 지원
_출시 가이드 - 패스키의 점진적 채택_은 패스키에 대한 조직의 지원을 가로막는 일반적인 장벽을 완화하도록 설계되었습니다. 이 전략은 다른 전략에 필요한 만큼 노력을 기울이지 않아도 되기 때문에, 패스키 프로젝트 책임자가 조직에서 전략을 진행하기 위한 지원을 받을 수 있는 경우가 많습니다. 다른 전략을 진행하려면 프레젠테이션을 여러 번 거치고 다양한 지역에 있는 여러 부서와 후속 대화를 이어가야 합니다. 하지만 이 전략에서는 패스키의 초기 출시에 수반되는 통합 마케팅 캠페인이 없기 때문에 마케팅 부서의 지원이나 승인이 거의 필요하지 않습니다. 이 전략은 디자인 패턴: 계정 설정에서 패스키 생성, 보기 및 관리에서 규정하는 것처럼 제품 변경이 극히 적고 사용자의 계정 설정 인터페이스로 한정되어 있기 때문에 제품 및 사용자 경험 팀의 지원이 거의 필요하지 않습니다.
조직의 지원을 간소화하는 한 가지 방법은 최초 패스키 구현을 특정한 운영 시스템의 주요 사용 사례 하나로 한정하는 것입니다. 예를 들어 어떤 온라인 서비스에서는 “패스키를 활용하여 새로운 iPhone으로 우리 앱이나 웹 사이트에 어려움 없이 로그인하게 사용자를 돕고 싶다”는 사용 사례부터 시작하고 싶을 수 있습니다. 이러한 사용 사례에서 패스키 구현이 필요한 유일한 환경은 iPhone입니다.
이 전술을 사용하면 초기 출시 비용과 범위를 최소한으로 유지하면서도 조직 고유의 비즈니스 환경에서 실제 패스키와 관련된 이점을 측정하고 비교할 수 있습니다. 이후 추가적인 운영 체제의 더 많은 사용 사례에 지원을 추가할 수 있습니다.
많은 조직의 경우 이 가이드를 살펴보는 사람이 프로젝트를 승인할 수도 있습니다. 그렇지 않은 조직의 경우 패스키 구현 프로젝트를 승인할 수 있는 의사 결정권자를 식별하는 프로세스를 완료해야 합니다. 패스키 프로젝트를 승인해야 하는 의사 결정자는 한 명일 수도 있고 여러 명의 의사 결정자로 구성된 위원회일 수도 있습니다.
조직 간 계획
이 가이드는 단일 부서 내의 단일 팀이 통합에 필요한 모든 주요 작업을 완료할 수 있도록 설계되었습니다. 이 가이드에는 필요한 조직 간 계획은 아주 적습니다. 예를 들어 위험 관리 및 사기 방지 부서와의 협업은 기존 인증 수단이 그대로 유지되기 때문에 거의 필요하지 않습니다. 이 전략에는 주요한 마케팅 캠페인이 없어 마케팅 부서와 협력할 필요도 없습니다. 이 전략은 사용 사례가 제한적인 단일 지역에만 적용되며 전 세계 다른 지역의 부서와 협력할 필요가 없습니다.
법무 및 컴플라이언스 팀
패스키는 환경에 새로운 인증 방식을 도입하며, 디지털 신원 및 인증과 관련된 규정 준수, 위험, 법률적 변경 사항을 관리하기 위해 완료해야 하는 작업이 있습니다. 조사 초기 단계에 법무 및 컴플라이언스 팀에 조직이 패스키의 사용을 평가하고 있음을 알리십시오. 법무 및 컴플라이언스 팀이 패스키에 대해 잘 모르는 경우 패스키에 대한 NIST(미국 국립표준기술연구소) 지침인 NIST 디지털 신원 지침 강화를 읽어볼 것을 제안하십시오. NIST 지침에서는 동기화된 패스키가 AAL2(인증 보증 수준 2)를 충족한다고 명시하고 있습니다. 모든 조직이 NIST 지침을 따라야 하는 것은 아니며, NIST는 미국 정부의 한 부분이지만 전 세계 대부분의 지역과 다양한 산업 분야의 기업에서 NIST를 권위 있는 출처로 여겨 정기적으로 참조합니다.
법무 팀에서는 일반적으로 사용자가 자신의 계정에서 패스키를 제거할 수 있도록 요구합니다. FIDO Alliance에서는 이 사실을 인식하고 패스키 삭제를 위한 디자인 패턴을 만들었습니다. 이 디자인 패턴은 사용자 경험 연구를 기반으로 하며 필요 시 이러한 법적 요구 사항을 충족하는 신뢰할 수 있는 사용자 경험 모델임이 입증되었습니다. 이 디자인 패턴은 법무 팀의 일반적인 요구 사항을 충족하는 것은 물론, 사람들에게 보안 설정을 제어하고 패스키를 삭제할 수 있는 권한을 부여함으로써 사용자의 신뢰와 만족도를 높여줍니다. 잊어버렸거나, 분실했거나, 손상된 패스키와 관련된 요청을 처리하는 데 필요한 지원 비용과 자원도 절감할 수 있습니다.
정보 기술(IT)
이 출시 전략에서는 기존의 모든 인증 기술 인프라가 그대로 유지되고 변경되지 않기 때문에 최소한의 IT 아키텍처 변경만 필요합니다.
패스키를 위한 두 가지 FIDO 시작하기 디자인 패턴을 지원하려면 FIDO 인증 서버 및 코드 베이스 추가를 위한 계획이 필요합니다.
필요한 기술 환경을 계획할 때는 패스키를 사용하는 인증 아키텍처에 대한 장기적인 비전을 고려하십시오. 한 가지 고려해야 할 점은 어떻게 패스키의 범위를 특정 도메인으로 한정할 것인지를 알아보는 것입니다. 초기 출시가 하나의 도메인에서 이루어지더라도 장기적으로 다양한 도메인에서 필요하게 될 수 있습니다. 예를 들어 마케팅 활동으로 하위 도메인을 사용해 마이크로 사이트를 개설하거나, 때로는 새로운 도메인을 개설할 수 있으며, 그러한 마이크로 사이트의 일부가 패스키를 사용하는 인증 서비스를 요구 할 수 있습니다. 이는 패스키에 대한 지원을 구현할 때 고려해야 할 수많은 IT 고려 사항 중 하나에 불과하지만, 이 전략에서 IT 변화 관리의 범위는 상대적으로 작습니다.
인증 정책
일부 조직에서는 인증 이벤트의 위험을 평가하기 위해 다양한 기술을 사용합니다. 로그인을 시도하는 신원에 대한 원격 측정 신호(예: IP 주소, 인증 기기의 운영 체제 버전, Wi-Fi 지문)는 사용자의 다음 단계를 결정하는 일련의 비즈니스 정책에 의해 처리됩니다. 이러한 기술은 추가적인 분석을 위해 이러한 데이터를 기록하는 동시에 로그인을 허용할 수도 있고, 로그인을 위해 추가적인 단계를 수행하도록 요청하거나 로그인을 차단할 수도 있습니다. 이 작업을 수행하는 데 사용되는 기술과 시스템의 집합은 흔히 _위험 엔진_이라고 불립니다.
패스키에는 피싱 방지와 같은 고유한 보안 특성이 있기 때문에 기업에서는 패스키를 위험 엔진 정책과 통합할 수 있습니다. 예를 들어 사용자가 패스키를 생성한 다음 위험 엔진이 해당 사용자의 이전 사용을 확인할 수 없는 장치와 비밀번호를 사용해 인증을 시도하면 위험 엔진은 해당 사용자가 올바른 계정 소유자가 맞는지 확인될 때까지 사용자가 수행할 수 있는 승인된 거래의 종류를 제한할 수 있습니다. 이는 패스키를 도입하여 수행할 수 있는 위험 엔진 정책 강화의 한 사례에 불과합니다. 수많은 다양한 접근 방식을 따르면 많은 정책을 강화할 수 있습니다.
이 전략에서는 초기에 위험 엔진 정책을 변경할 필요가 없다고 가정합니다. 하지만 초기 출시 이후 시간이 흐르면 패스키를 등록한 사용자 계정에 대한 위험 정책을 강화할 수 있습니다.
사용자 경험
점진적 출시 전략에서 사용자 경험을 최적화하기 위해 필요한 변화 관리 노력은 상당합니다. 잘 관리하지 못하면 사용자 경험에 부정적인 영향을 미칩니다.
예를 들어 엔지니어는 이해하지만, UX 디자이너나 콘텐츠 전략가는 이해할 수 없는 패스키 워크플로가 있습니다. 엔지니어에게 워크플로의 사용자 경험을 최적화하기에 충분한 시간이나 사용자 경험 지식, 또는 사용자 경험 연구 인사이트가 없을 수 있습니다.
대부분의 출시 전략에서 사용자 경험을 최적화하기 위해 필요한 변화 관리 노력은 상당합니다. 사용자 경험에 전문성이 없는 사람들이 사용자 경험에 직접적으로 영향을 미칠 결정을 내려야 합니다. 이를 잘 관리하지 못하면 사용자 경험이 고통스러워집니다.
또 다른 예로는 인증 정책의 변경과 기술 아키텍처에 대한 결정이 사용자 경험에 영향을 미칠 수 있다는 것입니다. 또한 운영 체제가 다른 사용자는 패스키에 대해 상이한 경험을 하게 되며, 이 또한 사용자 경험에 영향을 미칩니다.
이것이 바로 제품, 엔지니어링, 콘텐츠 전략, IT, 법무 및 사용자 경험 디자인 팀 간의 협력이 필요한 사용자 경험 항목들을 이해하고, 문서화하고, 해결하는 것이 누구의 업무인지를 고려하는 것이 중요한 이유입니다. 이 작업은 복잡미묘하고 많은 시간이 소요될 것으로 예상하고 계획을 세워야 합니다. 사용자 경험에 관한 결정을 조직 에 전달하고 조직 전체에서 적절히 해결해야 할 것입니다.
이 작업을 돕기 위해 패스키 작업을 하는 팀원은 디자인 가이드라인을 읽고 따라야 합니다.
빌드 및 테스트 과정을 거치면서 브라우저, 운영 체제, 자격 증명 관리자(비밀번호 관리자) 간의 기술이 일관적이지 않다는 것을 발견하게 될 것입니다. 일부 패스키 사용 사례에서 장벽에 직면하고, 사용자 여정에서 불만족스러운 경로롤 발견하게 될 것입니다. 이러한 문제를 미리 이해하려면 이 단계 이전, 도중 및 이후에 문제 해결을 참조합니다. 문제 해결 섹션에는 FIDO Alliance 회원사에서 패스키에 대한 지원을 구현하면서 얻은 교훈과 지침이 포함되어 있으며, 자체 구현 시 시간을 절약해 줄 것입니다.
사용자 교육
이 출시 전략을 사용하는 경우 조직 은 사용자에게 패스키에 관해 선제적으로 교육하지 않습니다. 대신 사용자는 계정 설정을 방문할 때 패스키를 사용하는 옵션을 자연스럽게 알게 됩니다. 이렇게 하면 패스키에 관해 사용자를 빠르게 교육하는 데 필요한 변화 관리 양이 크게 줄어듭니다.
