기능적 인증 및 권한 부여 시스템 설계

이번 글에서는 인증과 승인을 안전하게 수행하기 위한 시스템에 대해 이야기해보겠습니다. 먼저 인증과 권한 부여의 차이점을 이해해 보겠습니다.

• 인증은 애플리케이션에 액세스할 때 본인이 누구인지 증명하는 프로세스입니다.
• 승인은 액세스 정책을 정의하고 시행하는 프로세스입니다. 즉, 인증을 받은 후에 수행할 수 있는 작업입니다.

이 기사에서는 다음 내용을 살펴보겠습니다.

• 인증 및 권한 부여가 중요한 이유
• 인증 작동 방식
• 승인 작동 방식
• 인증 시스템 설계
• 결론

인증과 승인이 중요한 이유는 무엇입니까?

우리가 회의 중인데 당신이 대화를 주도하고 있다고 가정해 보겠습니다. 적합한 사람에게 업데이트/상태를 요청하려면 해당 사람을 식별(예: 인증 )해야 합니다. 민감한 데이터를 다른 사람과 공유하는 경우에도 해당 사람을 올바르게 인증해야 합니다. 그리고 그것이 바로 인증이 들어오는 곳입니다.

이제 동일한 회의에서 몇 가지 결정을 내려야 한다고 가정해 보겠습니다. 따라서 이를 위해서는 그러한 결정을 내릴 권리가 있는 사람들이 결정을 내리는 사람이 되어야 합니다. 모든 사람이 모든 것을 하도록 허용할 수는 없습니다. 분명히 어떤 사람들은 어떤 결정을 내릴 만큼 충분히 음식을 제공받지 못하고, 어떤 사람들은 확실히 최악의 상황을 만들려고 노력할 것입니다. 따라서 특정 사람들에게 특정 활동에 대한 권한을 부여하는 Authorization이 제공됩니다.

인증은 어떻게 작동하나요?

사람을 인증하기 위해 우리는 각 사람에게 고유한 문구를 할당할 수 있으며, 그 사람이 문구와 이름을 정확하게 말하면 주어진다. 우리는 그 사람의 신원을 확인했다고 말할 수 있습니다. 이는 일반적인 사용자 이름 및 비밀번호 접근 방식입니다. 올바른 자격 증명이 제공되면 시스템은 해당 ID가 유효한 것으로 간주하고 액세스 권한을 부여합니다. 이를 1FA 또는 단일 요소 인증 (SFA)이라고 합니다.

SFA는 상당히 안전하지 않은 것으로 간주됩니다. 왜? 사용자가 로그인 정보를 안전하게 유지하는 데 매우 취약하기 때문입니다. MFA(다단계 인증)는 사용자가 여러 가지 방법으로 자신의 신원을 증명해야 하는 보다 안전한 대안입니다. 그러한 방법 중 일부는 다음과 같습니다.

• 일회용 PIN 번호/OTP
• 안전한 제3자(예: Google/Microsoft Authenticator)가 실행하는 인증 앱
• 생체 인식

일단 인증되면 그 사람은 애플리케이션에서 자유롭게 작업을 계속 수행할 수 있습니다. 그리고 그 사람을 여행 내내 잊지 않고 알아볼 수 있도록 애플리케이션을 기대합니다. 이상적으로는 사용자가 다른 페이지로 이동하거나 어떤 활동을 할 때마다 비밀번호를 제공하도록 요청하는 것은 너무 많은 일입니다. 따라서 사용자가 자격 증명을 입력하고 한 번 인증된 후에 사용자를 계속 인증할 수 있는 방법이 필요합니다. 이것을 세션 관리 라고 합니다.

사용자 인증을 유지하는 두 가지 방법:

• 세션 기반 인증 : 사용자가 브라우저에서 웹 사이트에 로그인하면 서버는 해당 사용자에 대한 세션을 생성하고 세션 ID를 할당합니다. 이 세션 ID는 참조용으로 서버에 저장되며 브라우저의 쿠키에 저장되도록 사용자에게 다시 전송됩니다. 이제 사용자가 요청할 때마다 브라우저는 요청과 함께 sessionid를 보냅니다. 요청을 인증하는 데 도움이 됩니다. 따라서 사용자가 사이트에 있는 동안 인증이 유지됩니다.
• 토큰 기반 인증 : 이를 위해 서버는 사용자에게 전송되고 브라우저에만 HttpOnly 쿠키로 저장되는 암호화된 토큰을 생성합니다. 사용자 정보, 권한 및 토큰 만료와 같은 모든 필수 정보는 토큰 내에서 암호화됩니다. 토큰은 서버 호출을 위해 함께 전송됩니다. 서버는 단순히 비밀 키로 토큰을 해독하고 사용자를 확인합니다. 이 토큰은 일정 간격으로 새로 고쳐집니다.

이 두 접근 방식의 주요 차이점은 토큰 기반 인증이 Stateless 이므로 토큰을 서버 측에 저장할 필요가 없다는 것입니다. 그러나 세션 기반 인증의 경우 토큰을 서버 측에도 저장해야 하므로 Stateful이 됩니다. 시스템 규모가 확장되거나 사용자 수가 늘어나면 문제가 발생합니다.

토큰 기반 인증에는 주로 JWT(JSON Web Tokens)를 사용합니다.

승인은 어떻게 작동하나요?

사용자가 인증된 후에도 액세스 권한이 있는 리소스에만 액세스할 수 있도록 해야 합니다. 민감한 데이터에 대한 무단 액세스는 재앙이 될 수 있습니다. 최소 권한의 원칙에 따라 회사는 일반적으로 기본적으로 절대적으로 필요한 것에 액세스할 수 있도록 액세스 정책을 설정합니다. 그런 다음 계속해서 추가 액세스 권한을 갖게 됩니다. 액세스를 분할하는 일반적인 방법은 다음과 같습니다.

• 역할 기반 액세스 제어(RBAC) : 사용자는 설정된 권한과 함께 제공되는 특정 그룹/역할에 할당됩니다. 예: 관리자, 회원, 소유자.
• PBAC(Policy-based Access Control) : 정책과 규칙을 기반으로 승인 과정에서 접근 권한을 동적으로 결정합니다. 정책은 사용자 역할, 직무 및 조직 요구 사항을 기반으로 합니다.
• 속성 기반 액세스 제어(ABAC) : 사용자는 직함, 인증, 교육 및/또는 위치와 같은 환경 요인과 같은 속성에 따라 액세스가 허용됩니다.
• 액세스 제어 목록(ACL) : 각 사용자 또는 엔터티에는 휴대폰에 새 앱을 설치하고 부여할 권한(위치 서비스, 연락처 등)을 결정하는 것과 유사하게 켜거나 끌 수 있는 개별 권한이 있습니다.

ACL은 ABAC 또는 RBAC보다 세부적인 수준에서 자주 사용됩니다. 예를 들어 개별 사용자에게 특정 파일에 대한 액세스 권한을 부여하는 경우입니다. ABAC와 RBAC는 일반적으로 전사적 정책으로 제정됩니다.

인증 시스템 설계

요구사항

먼저 시스템의 기능 요구 사항을 정의하는 것부터 시작해 보겠습니다.

• 등록 : 필요한 정보를 제공하여 사용자가 등록할 수 있도록 합니다.
• 로그인 : 자격 증명을 기반으로 사용자를 인증합니다.
• 세션 관리 : 보안을 보장하기 위해 사용자 세션을 효율적으로 관리합니다.
• 비밀번호 복구 : 사용자가 비밀번호를 복구할 수 있는 안전한 프로세스를 제공합니다.
• 액세스 제어 : 다양한 사용자 유형에 대한 역할 및 권한을 정의합니다.
• 감사 추적 : 감사를 위해 인증 이벤트에 대한 자세한 로그를 유지합니다.
• 성능 : 낮은 대기 시간과 빠른 응답 시간을 보장합니다.

이 문서의 범위에서 고려하지 않을 몇 가지 비기능적 요구 사항은 다음과 같습니다.

• 다단계 인증(MFA) : 강력한 MFA 시스템을 구현합니다.
• 보안 : 암호화, 안전한 저장, 안전한 통신을 통해 데이터 보안을 최우선으로 생각합니다.
• 확장성 : 점점 늘어나는 사용자와 트랜잭션을 처리할 수 있도록 시스템을 설계합니다.
• 신뢰성 : 시스템 다운타임을 최소화하고 고가용성을 보장합니다.
• 유용성 : 원활한 경험을 위해 직관적인 사용자 인터페이스를 개발합니다.

용량 추정

트래픽 견적

먼저 트래픽 견적 부터 시작해 보겠습니다. 월 평균 트래픽을 100,000으로 가정합니다. 월간 사용자 트래픽은 100,000으로 추정됩니다. 이는 초당 0.04 요청으로 해석됩니다. 우리는 90%의 시간 동안 500ms 이내에 각 요청에 응답해야 합니다. 즉, 500ms의 p90 대기 시간이 필요합니다.

 assumed_traffic_per_month = 100000 #requests assumed_traffic_per_day = assumed_traffic_per_month / 30 ~= 3350 (assuming on higher end; 3333.33 to be precise) estimated_time_per_request = 500 #ms; P90 of 500ms traffic_per_second = (assumed_traffic_per_month) / (30*24*60*60) = 0.04

서비스 수준 목표(SLO) : 500ms(허용 가능한 최대 지연 시간, 시스템 부하와 무관) 계산에 따르면 인스턴스 1개가 취할 수 있는 평균 용량은 요청에 대해 과도한 처리가 발생하지 않는다는 가정 하에 요청을 처리하는 데 약 35ms입니다. 특별한 요청.

위 측정항목을 사용하여 두 개의 파생 측정항목을 더 생성해 보겠습니다.

• 용량 : 인스턴스당 허용 가능한 백로그: SLO를 손상시키지 않고 인스턴스에서 허용할 수 있는 최대 요청(로드) 수입니다.
• 수요 : 인스턴스당 백로그 : 현재 트래픽을 기준으로 유닛/인스턴스로 유입되는 총 요청(로드) 수입니다.

따라서,

 SLO = 500ms approx_response_time_for_one_request = 35 #ms capacity = SLO/approx_response_time_for_one_request = 500 / 35 ~= 20 load_on_one_instance = 0.04 instances_available = 1 demand = traffic_per_second / instances_available = 0.04

수요와 사용 가능한 용량을 바탕으로 필요한 총 인스턴스 수를 계산해 보겠습니다.

 total_units_required = demand / capacity = 0.04 / 20 = 0.002 ~= 1

따라서 우리는 1개의 인스턴스로 초당 0.04개의 요청으로 월별 100,000개의 요청을 쉽게 처리할 수 있습니다. 각 장치는 SLO를 손상시키지 않고 초당 20개의 요청을 처리할 수 있습니다.

스토리지 추정

인증 및 권한 부여 액세스를 위해 각 사용자의 사용자 세부 정보를 저장하는 것이 이상적으로 필요합니다. 가정, 5kb/user

 monthly_new_users = 500 monthly_additional_storage = 500 * 5kb = 2500kb ~= 2GB

따라서 매달 500명의 신규 사용자를 온보딩한다고 가정하면 2GB의 추가 스토리지가 필요합니다. 경우에 따라 인증 로그를 보관하고 싶습니다. 각 인증 요청을 저장하는 데 2kb가 소요될 것으로 예상됩니다.

 auth_request_size = 2kb #assumption monthly_storage = monthly_visitors * auth_request_size = 100,000 * 2KB ~= 200MB

따라서 월간 트래픽이 100,000이라고 가정하면 매달 추가로 200MB가 필요합니다.

데이터베이스 디자인

이제 용량 추정이 완료되었습니다. 기능적 요구 사항을 지원하는 데 필요한 데이터베이스의 스키마를 생성해 보겠습니다.

빠르게 테이블을 살펴보겠습니다. 우리는 6개의 테이블을 사용하고 있습니다.

1. 사용자 - 모든 사용자 정보를 저장합니다.
2. 자격 증명 - 사용자가 승인되면 액세스/새로 고침 자격 증명을 저장합니다.
3. 비밀번호 - 사용자의 암호화된 사용자 비밀번호를 저장합니다.
4. PasswordRequests - 특정 사용자에 대한 비밀번호 변경 요청을 저장합니다.
5. 세션 - 사용자가 활성 세션을 가졌던 시간과 마지막 활동이 있었던 시간을 저장합니다.
6. ActivityApproval - 특정 사용자가 수행한 활동에 대한 승인 요청을 저장하고 관리자가 확인합니다.

인증 시스템을 위한 높은 수준의 설계

시스템 엔드포인트

요구사항 이행

이제 모든 것이 준비되었으므로 모든 요구 사항을 완료할 수 있는 방법을 살펴보겠습니다.

등록

• 요구 사항 - 새로운 사용자가 우리 애플리케이션을 방문할 때. 다음에 사용자가 방문할 때 사용자를 인증/식별할 수 있도록 사용자 세부 정보를 저장해야 합니다.
• 이행 - 신규 사용자가 애플리케이션을 방문하여 이메일 및 비밀번호와 함께 사용자 세부 정보를 입력하는 경우입니다. 이는 데이터베이스에 캡처됩니다. 사용자 세부 정보는 사용자 테이블에 저장됩니다. 그리고 비밀번호는 암호화된 형태로 자격 증명 테이블에 저장됩니다.

로그인

• 요구 사항 - 기존 사용자가 우리 애플리케이션을 방문할 때. 우리는 사용자의 활동을 승인/식별하고 사용자에게 속한 데이터를 표시할 수 있도록 사용자를 식별해야 합니다.
• 이행 - 기존 사용자가 애플리케이션을 방문하여 세부 정보, 이메일 및 비밀번호를 입력하는 경우입니다. 우리는 비밀번호를 해시하고 자격 증명 테이블에 있는 사용자에 대해 저장된 해시와 해시를 일치시킵니다. 일치하면 사용자를 성공적으로 식별할 수 있습니다. 그렇지 않으면 등록 시 입력한 올바른 비밀번호를 입력해야 합니다. 이 프로세스를 인증 이라고 합니다.

세션 관리

• 요구 사항 - 사용자가 사용자와 비밀번호를 입력하여 자신을 인증한 경우. 우리는 그들이 향후 작업을 수행할 때/민감한 데이터를 보려고 시도할 때 비밀번호를 반복해서 입력하지 않고 로그인 상태를 유지하도록 해야 합니다.
• 이행됨 - 사용자가 성공적으로 인증된 경우입니다. 인증 서버는 클라이언트와 2개의 토큰을 공유합니다. access_token 및 Refresh_token . access_token은 암호화된 데이터를 가질 수 있으며 보안상의 이유로 만료 시간이 짧습니다. 클라이언트가 access_token을 갖게 되면 요청을 인증하는 데 도움이 되는 모든 요청과 함께 access_token을 다시 보냅니다. access_token이 만료되면 클라이언트는 제공된 Refresh_token을 사용하여 새 access_token을 요청해야 합니다. 이는 세션을 유지하는 데 도움이 됩니다.

비밀번호 복구

• 요구 사항 - 사용자가 비밀번호를 잊어버린 경우 비밀번호를 안전하게 재설정할 수 있어야 합니다.
• 이행 - 사용자가 비밀번호를 잊어버린 경우 비밀번호 찾기 페이지에 이메일 주소를 제출할 수 있으며, 당사에서는 일회용 코드를 생성하여 해당 이메일에 대한 링크를 보냅니다. 사용자가 코드와 이메일 주소로 이 링크를 클릭할 때. 우리는 비밀번호 복구 요청이 진짜인지 안전하게 식별할 수 있습니다. 그리고 사용자에게 새 비밀번호를 설정하도록 제공하세요. 따라서 비밀번호를 복구할 수 있습니다.

액세스 제어

• 요구 사항 - 사용자가 특정 작업을 수행할 때 사용자가 해당 작업을 수행하도록 인증되었는지 확인한 다음 해당 작업이 발생하도록 허용해야 합니다.
• 이행 - 단순화를 위해 1~12개의 작업 목록을 유지합니다. 각 사용자에 대해 해당 사용자에 대해 인증된 작업을 유지 관리합니다. 이제 사용자가 작업 #id 4를 수행하려고 한다고 가정해 보겠습니다. 사용자에게 작업 4를 수행할 권한이 있는지 확인합니다. 그렇다면 요청을 완료합니다. 그렇지 않으면 권한 부족으로 인해 요청이 성공하지 못했음을 보여줍니다.

감사 추적

• 요구 사항 - 보안 사고가 발생한 경우 조사할 수 있는 충분한 로그가 있어야 하며, 무슨 일이 일어났는지에 대한 타당한 이유나 가능한 원인이 무엇인지에 대한 단서가 있어야 합니다.
• 이행 - 이러한 시나리오의 경우 서버에서 발생하는 모든 인증 작업에 대한 로그를 유지할 수 있습니다. (ㅏ). 각 로그인 요청에 대해 인증이 발생한 시간, 위치, IP 및 기타 관련 세부 정보에 대한 로그를 유지합니다. (비). 각 비밀번호 복구 요청에 대해 당사는 요청이 시작된 시간, IP 주소, 요청 완료 여부 및 기타 관련 세부 정보에 대한 로그를 유지합니다. (씨). 또한, 우리는 사용자가 작업에 대해 승인/승인을 받을 때마다, 그리고 누구에 의해 로그를 보관할 것입니다. 이러한 로그는 모두 일부 시나리오를 이해하려고 할 때 어떤 일이 발생했는지 나타낼 수 있어야 합니다.

성능

• 요구 사항 - 용량 추정 섹션에서 설명한 대로 성능 요구 사항은 초당 0.04개 요청, 월별 요청 100,000개입니다.
• 이행됨 - 용량 추정 섹션에서 충분한 서버에 대한 요구 사항을 이미 처리했습니다.

결론

이 기사에서는 인증과 권한 부여의 차이점을 이해하는 것부터 시작했습니다. 다음으로 인증 및 권한 부여 시스템을 만들었습니다. 이는 안전하고 안전하며 성능을 제공하는 동시에 업계 표준을 충족하고 원하는 모든 요구 사항을 충족합니다. 앞으로는 관련성을 유지하고 그러한 시스템 구축에 대한 더 많은 정보와 통찰력을 다루기 위해 기사의 특정 부분을 업데이트할 수 있습니다.