이번 글에서는 인증과 승인을 안전하게 수행하기 위한 시스템에 대해 이야기해보겠습니다. 먼저 인증과 권한 부여의 차이점을 이해해 보겠습니다.
이 기사에서는 다음 내용을 살펴보겠습니다.
우리가 회의 중인데 당신이 대화를 주도하고 있다고 가정해 보겠습니다. 적합한 사람에게 업데이트/상태를 요청하려면 해당 사람을 식별(예: 인증 )해야 합니다. 민감한 데이터를 다른 사람과 공유하는 경우에도 해당 사람을 올바르게 인증해야 합니다. 그리고 그것이 바로 인증이 들어오는 곳입니다.
이제 동일한 회의에서 몇 가지 결정을 내려야 한다고 가정해 보겠습니다. 따라서 이를 위해서는 그러한 결정을 내릴 권리가 있는 사람들이 결정을 내리는 사람이 되어야 합니다. 모든 사람이 모든 것을 하도록 허용할 수는 없습니다. 분명히 어떤 사람들은 어떤 결정을 내릴 만큼 충분히 음식을 제공받지 못하고, 어떤 사람들은 확실히 최악의 상황을 만들려고 노력할 것입니다. 따라서 특정 사람들에게 특정 활동에 대한 권한을 부여하는 Authorization이 제공됩니다.
사람을 인증하기 위해 우리는 각 사람에게 고유한 문구를 할당할 수 있으며, 그 사람이 문구와 이름을 정확하게 말하면 주어진다. 우리는 그 사람의 신원을 확인했다고 말할 수 있습니다. 이는 일반적인 사용자 이름 및 비밀번호 접근 방식입니다. 올바른 자격 증명이 제공되면 시스템은 해당 ID가 유효한 것으로 간주하고 액세스 권한을 부여합니다. 이를 1FA 또는 단일 요소 인증 (SFA)이라고 합니다.
SFA는 상당히 안전하지 않은 것으로 간주됩니다. 왜? 사용자가 로그인 정보를 안전하게 유지하는 데 매우 취약하기 때문입니다. MFA(다단계 인증)는 사용자가 여러 가지 방법으로 자신의 신원을 증명해야 하는 보다 안전한 대안입니다. 그러한 방법 중 일부는 다음과 같습니다.
일단 인증되면 그 사람은 애플리케이션에서 자유롭게 작업을 계속 수행할 수 있습니다. 그리고 그 사람을 여행 내내 잊지 않고 알아볼 수 있도록 애플리케이션을 기대합니다. 이상적으로는 사용자가 다른 페이지로 이동하거나 어떤 활동을 할 때마다 비밀번호를 제공하도록 요청하는 것은 너무 많은 일입니다. 따라서 사용자가 자격 증명을 입력하고 한 번 인증된 후에 사용자를 계속 인증할 수 있는 방법이 필요합니다. 이것을 세션 관리 라고 합니다.
사용자 인증을 유지하는 두 가지 방법:
이 두 접근 방식의 주요 차이점은 토큰 기반 인증이 Stateless 이므로 토큰을 서버 측에 저장할 필요가 없다는 것입니다. 그러나 세션 기반 인증의 경우 토큰을 서버 측에도 저장해야 하므로 Stateful이 됩니다. 시스템 규모가 확장되거나 사용자 수가 늘어나면 문제가 발생합니다.
토큰 기반 인증에는 주로 JWT(JSON Web Tokens)를 사용합니다.
사용자가 인증된 후에도 액세스 권한이 있는 리소스에만 액세스할 수 있도록 해야 합니다. 민감한 데이터에 대한 무단 액세스는 재앙이 될 수 있습니다. 최소 권한의 원칙에 따라 회사는 일반적으로 기본적으로 절대적으로 필요한 것에 액세스할 수 있도록 액세스 정책을 설정합니다. 그런 다음 계속해서 추가 액세스 권한을 갖게 됩니다. 액세스를 분할하는 일반적인 방법은 다음과 같습니다.
ACL은 ABAC 또는 RBAC보다 세부적인 수준에서 자주 사용됩니다. 예를 들어 개별 사용자에게 특정 파일에 대한 액세스 권한을 부여하는 경우입니다. ABAC와 RBAC는 일반적으로 전사적 정책으로 제정됩니다.
먼저 시스템의 기능 요구 사항을 정의하는 것부터 시작해 보겠습니다.
이 문서의 범위에서 고려하지 않을 몇 가지 비기능적 요구 사항은 다음과 같습니다.
트래픽 견적
먼저 트래픽 견적 부터 시작해 보겠습니다. 월 평균 트래픽을 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 = 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개의 테이블을 사용하고 있습니다.
시스템 엔드포인트
엔드포인트 | 설명 |
---|---|
/로그인 | 사용자 자격 증명을 인증합니다. |
/로그 아웃 | 사용자 세션을 종료하고 인증 토큰을 취소합니다. |
/등록하다 | 새 사용자를 만듭니다. |
/업데이트/:사용자 ID | 사용자 정보를 업데이트하세요. |
/삭제/:사용자 ID | 사용자 계정을 삭제합니다. |
/grant/:userId/:허가 | 사용자에게 특정 권한을 부여합니다. |
/revoke/:userId/:허가 | 사용자의 권한을 취소합니다. |
/check/:userId/:자원 | 특정 리소스에 대한 사용자의 액세스를 확인합니다. |
/create/:사용자 ID | 새로운 사용자 세션을 생성합니다. |
/만료/:세션ID | 사용자 세션을 만료합니다. |
/validate/:sessionId | 활성 사용자 세션의 유효성을 검사합니다. |
요구사항 이행
이제 모든 것이 준비되었으므로 모든 요구 사항을 완료할 수 있는 방법을 살펴보겠습니다.
등록
로그인
세션 관리
비밀번호 복구
액세스 제어
감사 추적
성능
이 기사에서는 인증과 권한 부여의 차이점을 이해하는 것부터 시작했습니다. 다음으로 인증 및 권한 부여 시스템을 만들었습니다. 이는 안전하고 안전하며 성능을 제공하는 동시에 업계 표준을 충족하고 원하는 모든 요구 사항을 충족합니다. 앞으로는 관련성을 유지하고 그러한 시스템 구축에 대한 더 많은 정보와 통찰력을 다루기 위해 기사의 특정 부분을 업데이트할 수 있습니다.