한국어
  • mfa
  • auth
  • authentication
  • product

MFA 탐색: 제품 관점에서 본 인증

다요소 인증 (MFA) 의 핵심 구성 요소, 사용자 프로세스, 필수 지침 원칙을 분석하여 분해합니다.

Ran
Ran
Product & Design

디지털 환경에서 모든 앱이 동일한 방식으로 로그인할 때, 우리가 누구인지를 증명하는 방법을 단순화하여 시간과 자원을 절약할 수 있을까요? 가능할 것처럼 들리죠? 모든 것에 "Google로 계속하기"를 사용하거나 모든 것을 위해 단 하나의 이메일과 비밀번호 조합을 사용하는 것처럼.

하지만 실제 이야기는 더 흥미롭습니다. 각 앱은 로그인하는 사람이 정말 본인인지 확인하기 위한 고유한 방식을 가지고 있습니다. 우리는 보안을 유지하고, 사용자 경험을 균형있게 하고, 사용자별로 프라이버시 선호도를 존중하기 위해 이 확인 과정에 노력을 기울입니다.

모두에게 공통의 마법 공식은 없으므로, 확인이 어떻게 작동하는지를 분석하고 서비스에 맞는 디자인을 만들어봅시다.

기본 사항: 인증의 두 부분

인증, 즉 당신이 누구인지를 확인하는 프로세스는 식별자와 인증 요소의 두 가지로 구성됩니다.

식별자는 "안녕, 나는 사라야"라고 말하는 것과 같습니다. 당신은 "오, 저건 사라구나, 좋아."라고 생각할 수 있습니다. 하지만 보안 담당자들은 "이 사람이 정말 사라인가? 사라가 접근하기에 필요한 자격을 가지고 있는가?"라고 묻습니다. 이때 인증 요소가 등장합니다. 기술적 용어로 설명해 보겠습니다.

식별자: 당신의 디지털 신분증

식별자는 사용자가 접근할 수 있는 범위를 결정합니다. 자원이 항상 부족하기 때문에, 당신의 신분이 곧 당신의 유일한 통행 패스입니다. 1단계: 로그인 페이지에 식별자를 입력하세요. 하지만 별명이나 이름 전체로는 범용 검색이 될 가능성이 있습니다. 사용할 수 있는 식별자는 다음과 같습니다:

  • 사용자 ID: 기술적으로 변하지 않으며 고유합니다. 관리자 관리용이지만 사용자는 각 제품마다 이를 기억할 수 없습니다.

  • 사용자 이름: 사용자 친화적이고 사용자 ID의 반복입니다. 고유하며 계정 시스템 내에서 중복되지 않습니다. 소셜 플랫폼은 프로필을 개인화하지만 인식 유지를 위해 사용자 이름이 반드시 필요합니다. 변경 범위가 제한적이어서 비용을 지불해야 할 수도 있습니다.

  • ID 번호: 신분증, 학생증 또는 은행 카드 번호와 같은 고유 식별자입니다. 쉽게 기억되지는 않지만, 주요 ID를 잊어버렸을 때 신뢰할 수 있는 백업 메커니즘으로 회수할 수 있습니다.

  • 이메일 또는 전화번호: 사용자 이름과 달리 연락처 정보는 더 기억하기 쉽습니다. 이메일 또는 전화번호를 식별자로 사용하면 장기적으로 기억할 가능성을 줄여 잠재적 이탈 위험을 줄일 수 있습니다. 이러한 편리함은 사용자 친화적이지만 "개인, 이메일, 계정" 사이의 상호 작용을 관리하는 것은 제품 구조를 복잡하게 만들 수 있습니다. 인스타그램을 예로 들어봅시다: (1) 단일 이메일을 사용하여 여러 계정을 허용합니다; (2) 여러 이메일 주소를 로그인이나 복구에 대응하는 인스타그램 프로필에 추가할 수 있습니다; (3) 계정의 자원은 대개 분리되어 있지만 인스타그램은 계정 정보를 병합하여 통일된 검증, 타겟 광고와 개인 맞춤 추천을 촉진할 수 있습니다.

    Email

인증 요소

인증 요소는 당신이 진짜 본인임을 증명하는 움직임입니다. 선택할 수 있는 많은 요소들이 속성에 따라 나뉩니다:

의미인증 요소
지식당신이 알고 있는 것비밀번호, 이메일 인증 코드, 백업 코드
소유당신이 가지고 있는 것SMS 인증 코드, 인증 앱 OTP, 하드웨어 OTP (보안 키), 스마트 카드
고유당신 자신지문, 얼굴 인식 등의 생체 정보

이론적으로 당신은 이러한 인증 요소를 어떤 식별자와 결합하여 당신임을 증명할 수 있습니다. 일반적인: 이메일 주소(ID)와 이메일 인증 코드(요소). 하지만 다양하게 조합할 수 있습니다: 이메일 주소(ID)와 SMS 인증 코드(요소).

악의가 숨어있기 때문에 단일 요인은 충분하지 않습니다. 다요소 인증 (MFA)이 필요한 이유입니다. 로그인할 때 첫 번째 단계 인증(1FA)은 필수이지만 두 번째(2FA), 심지어 세 번째도 있을 수 있습니다. 또한 앱 내에서 중요한 자원에 접근을 요청할 때에는 신분을 재확인해야 합니다. 이러한 추가 레이어는 악의적 행위자에 대한 강화된 보안을 제공합니다. 이것이 전체 범위의 MFA입니다.

MFA

인증 흐름을 설계하세요

처음으로 돌아가서 – 왜 각 앱은 다른 식별자와 인증 요인 조합을 가질까요? 사용자 경험에 관한 것입니다.

인증이 너무 엄격하면 사용자가 "왜 이렇게 어려운가?"라고 생각하며 짜증낼 수 있습니다. 너무 느슨하면 해킹된 계정과 혼란이 발생할 수 있습니다. 그래서, 문제는 누구의 것인가요?

세 가지 안무 원칙:

진짜 사용자만 접근할 수 있도록 보장하세요

사람들은 가끔 ID를 잊어버리거나 인증 단계를 잃어버립니다. 잠재적 지원 부담을 줄이기 위해 방법을 세워야 합니다:

  1. 여러 인증 요인을 제공하세요 – 보통 MFA의 경우 최소 두 개 이상. 생체 정보는 멋지지만 인식되지 않을 때 작동하지 않고 때로는 사용자가 장치를 잃어버립니다.
  2. 인증을 복구할 수 있는 옵션을 제공하세요 – "비밀번호 찾기"나 다시 ID를 찾는 것과 같은 것들. 그러나 복구 전에 초기 신분 확인이 필요하며, 이는 보통 로그인 과정과 다릅니다.
  3. 고객 서비스나 관리자를 통한 연락처 정보를 복구 수단으로 제공하세요.

허점 없는 인증

이중 인증이 항상 더 안전하지 않듯이 인증도 완벽하지 않습니다. 기억하세요:

  1. MFA 흐름에서, 두 번째 인증 단계는 첫 번째와 다른 속성(지식/소유/고유)이어야 합니다. 예를 들어, "비밀번호(지식)"를 1FA로 사용하고 "인증 앱 OTP(소유)"를 2FA로 사용하면 다양한 공격 벡터를 막을 수 있습니다.
  2. 복구 방법은 MFA를 생략할 수 없습니다. 예를 들어, SMS로 "비밀번호 찾기"가 가능하다면 SMS를 두 번째 인증 요소로 사용할 수 없습니다. 또 다른 옵션은 "비밀번호 찾기" 과정에 2FA를 추가하는 것입니다. 이는 복잡해 보일 수 있지만.
  3. 코드 제한 시간 또는 비율 제한을 고려하세요. 여러 번의 잘못된 인증 시도 후에, 후속 인증의 비율을 제한합니다. 다단계 인증에서 단계 간 간격을 길게 두지 마십시오.

사용자 경험의 균형

모든 행동이 1FA 또는 2FA를 요구하는 것은 아닙니다. 항상 동일한 단계를 따르는 것이 아니라 상황에 따라 달라집니다.

  1. 다양한 역할에 맞춤형 용량을 제공합니다: 자원의 보안을 보장하는 것은 주로 제품의 책임이지만, 개개인의 의무이기도 합니다. MFA를 의무화하는 전략은 서비스의 성격에 따라 맞춤화될 수 있습니다: 앱 내의 보편적 사용자 MFA, 조직 주도형 MFA, 사용자 결정 주도형 MFA 등.
  2. 적응형 MFA를 활용하세요: 잠재적 위험을 수반하는 시나리오나 고위험 작업에는 인증 요구가 실용적입니다. 반면에 안전한 환경이나 저위험 작업에는 유지된 세션, 최소화한 인증 단계, 심지어 게스트 액세스를 통한 간소화된 접근이 필요할 수 있습니다. 특히 사용자 컨텍스트를 고려하여 의존합니다.
    • 불안정한 환경: 새로운 장치, 특이한 여행지, 신뢰할 수 없는 IP 등.
    • 민감한 행동: 암호화된 데이터 접근, 대규모 금융 거래, 인증 방법 변경 등이 해당됩니다.

자세한 내용은 NIST의 인증 보증 수준(AAL) 지침을 확인하세요.

마무리

인증과 다요소 인증 (MFA)의 탐험을 마치면서, 우리가 디지털 생활에서 그들이 하는 중요한 역할에 대한 인사이트를 얻게 되기를 바랍니다. 식별자와 인증 요소를 혼합하는 MFA는 안전한 접근을 유지하면서 사용자 친화적인 상호작용을 제공하는 견고한 방패를 형성합니다.

흥미로운 소식은 Logto의 MFA가 곧 나온다는 것입니다. Logto는 개인과 비즈니스를 위한 안전한 온라인 상호작용을 보장합니다.