authorization

6 개의 포스트

gitlab

GitLab 패치 릴리스: 19.2.2, 19.1.4, 19.0.6 | GitLab 문서 (새 탭에서 열림)

2026년 8월 12일 GitLab은 CE/EE용 패치 릴리스 19.2.2, 19.1.4, 19.0.6을 공개했다. 이번 릴리스에는 Analytics Dashboards, CI/CD, Duo Workflow, 프로젝트 권한, GraphQL API 등과 관련된 다수의 보안 취약점이 수정되었으므로, 영향을 받는 자체 관리형 GitLab은 즉시 업그레이드해야 한다. GitLab.com은 이미 패치가 적용되었으며, GitLab Dedicated 고객은 별도 조치가 필요 없다. ## 릴리스 대상과 업그레이드 권고 - 대상 버전: - GitLab 19.2 → 19.2.2 - GitLab 19.1 → 19.1.4 - GitLab 19.0 → 19.0.6 - CE와 EE 모두에 적용되는 수정이 포함되어 있다. - 별도의 배포 방식이 명시되지 않은 취약점은 Omnibus, 소스 설치, Helm Chart 등 모든 배포 유형에 영향을 준다. - 취약 버전을 사용하는 자체 관리형 설치 환경은 가능한 한 빨리 최신 패치 릴리스로 업그레이드해야 한다. - GitLab은 정기 패치 릴리스를 매월 둘째·넷째 수요일에 제공하며, 심각도가 높은 취약점에는 비정기 긴급 패치를 배포한다. - 보안 취약점의 상세 이슈는 패치된 릴리스 이후 90일이 지나면 공개된다. ## Analytics Dashboards의 XSS 취약점 - **CVE-2026-15217** - Analytics Dashboards의 표 셀 설정값을 제대로 무해화하지 않아 저장형 또는 반사형 XSS가 발생할 수 있었다. - CVSS 8.7. - **CVE-2026-15216** - Analytics Dashboards의 페이지네이션 컨트롤에 렌더링되는 사용자 제어 데이터의 검증이 부족했다. - 이를 통해 XSS가 발생할 수 있었으며 CVSS는 8.7이다. - 두 취약점의 영향 범위: - 18.2 이상 19.0.6 미만 - 19.1.4 미만의 19.1 버전 - 19.2.2 미만의 19.2 버전 - 두 문제 모두 HackerOne 버그 바운티를 통해 보고되었다. ## CI/CD 및 작업 확인 모달의 권한·XSS 문제 - **CVE-2026-15423** - Developer 권한 사용자가 필요한 push 권한 없이 보호 브랜치에서 CI/CD 파이프라인을 실행할 수 있었다. - 파이프라인 참조 검증 과정의 권한 확인이 부적절했던 것이 원인이다. - CVSS 8.5. - 19.0.6, 19.1.4, 19.2.2에서 수정되었다. - **CVE-2026-16627** - CI 수동 작업 확인 모달에서 HTML 콘텐츠를 제대로 정제하지 않아 권한 상승으로 이어질 수 있는 XSS가 발생할 수 있었다. - Developer 권한 인증 사용자가 공격을 수행할 수 있으며 CVSS는 7.7이다. - 19.2.2에서 수정되었다. ## Duo Workflow와 프로젝트 설정 권한 우회 - **CVE-2026-19228** - GitLab EE의 Duo Workflow Service에서 요청에 포함된 identity 정보를 적절히 검증하지 않았다. - 인증된 사용자가 AI 사용량을 다른 네임스페이스에 귀속시킬 수 있었다. - CVSS 8.5. - GitLab 내부 팀원이 발견했으며, 19.1.4와 19.2.2에서 수정되었다. - **CVE-2026-16494** - ProjectsController의 프로젝트 업데이트 엔드포인트에 권한 검사가 누락되었다. - 인증된 사용자가 상위 권한이 필요한 프로젝트 설정을 변경할 수 있었다. - CVSS 7.1. - GitLab EE의 19.1.4 및 19.2.2에서 수정되었다. ## GraphQL API의 서비스 거부 취약점 - **CVE-2026-7427** - GraphQL API의 JSON 파서가 비정상 입력을 충분히 검증하지 않았다. - 인증되지 않은 공격자가 특수한 입력을 보내 서비스 거부(DoS)를 유발할 수 있었다. - CVSS 5.3. - 18.5 이상 19.0.6 미만, 19.1.4 미만의 19.1, 19.2.2 미만의 19.2 버전이 영향을 받는다. ## Merge Request 및 외부 상태 검사 정보 노출 - **CVE-2026-6821** - Merge Requests API의 권한 검사가 누락되어 IP 기반 접근 제한을 우회할 수 있었다. - 인증된 사용자가 비공개 프로젝트의 Merge Request 일부 정보를 읽을 수 있었다. - CVSS 4.3. - GitLab EE 12.0부터 최신 패치 이전 버전까지 광범위하게 영향을 받는다. - **CVE-2026-4879** - 외부 상태 검사 API에서 권한 검사가 부족했다. - Developer 권한 사용자가 상위 권한으로 제한된 외부 상태 검사 설정을 조회할 수 있었다. - CVSS 4.3. - 16.0 이후 19.0.6, 19.1.4, 19.2.2 이전 버전에 영향을 준다. ## npm 패키지 메타데이터 권한 우회 - **CVE-2026-8667** - npm `dist-tags` 엔드포인트의 권한 검사가 부정확했다. - Developer 권한 사용자가 Maintainer 권한 없이 일부 패키지 레지스트리 메타데이터를 수정할 수 있었다. - CVSS 4.3. - 17.6 이후의 19.0.6, 19.1.4, 19.2.2 이전 버전이 영향을 받는다. 자체 관리형 GitLab 운영자는 사용 중인 메이저·마이너 버전에 맞춰 19.0.6, 19.1.4 또는 19.2.2로 즉시 업그레이드하고, 업그레이드 전후에 보호 브랜치·프로젝트 설정·API 접근 권한을 점검하는 것이 좋다.

gitlab

GitLab Duo Security Review, 스캐너가 놓치는 논리 결함 발견 (새 탭에서 열림)

정적 보안 스캐너는 SQL 인젝션이나 하드코딩된 비밀처럼 알려진 패턴에는 강하지만, 애플리케이션의 권한 모델과 업무 흐름을 이해해야 발견할 수 있는 논리적 취약점에는 한계가 있습니다. GitLab Duo Security Review의 Security Review Flow는 MR의 변경 내용을 주변 코드와 함께 분석해 권한 누락, 정보 노출, 비즈니스 로직 오류, 경쟁 조건 등을 찾아냅니다. 퍼블릭 베타 단계이며, 기존 스캐너와 수동 보안 검토를 보완하는 용도로 설계되었습니다. ## 패턴 기반 스캐너가 놓치는 취약점 - 코드 한 줄만 보면 정상적으로 보이지만, 애플리케이션의 도메인 규칙을 위반하는 문제가 주요 대상입니다. - **접근 제어 및 권한 문제** - 객체 ID만 바꿔 다른 사용자의 데이터를 조회하는 BOLA(Broken Object Level Authorization) - 관리자 전용 기능이나 상태 변경 작업에 대한 권한 검사 누락 - **데이터 노출** - 객체를 직렬화해 반환하는 코드는 문법상 문제가 없어도, 민감한 필드가 포함되면 정보 노출이 발생할 수 있습니다. - 어떤 필드가 민감한지, 어떤 사용자가 받아도 되는지는 도메인 지식이 필요합니다. - **제어 흐름과 업무 로직** - 결제 없이 주문 완료 단계에 접근 - 가격을 결정하는 파라미터를 조작 - 특정 상태에 반복 진입 - 동시 요청으로 상태 검증을 우회하는 경쟁 조건(race condition) ## MR마다 보안 판단을 적용하는 Security Review Flow - GitLab Duo Agent Platform의 기능으로, 코드 변경 시점에 보안 검토를 수행합니다. - 다음 유형의 문제를 탐지하도록 설계되었습니다. - 객체 수준 및 함수 수준 권한 우회 - 상태 변경 작업의 권한 검사 누락 - 정보 노출 및 대량 할당(mass assignment) - 비즈니스 로직 오류 - 상태 기반 워크플로의 경쟁 조건 - 수동 보안 리뷰나 침투 테스트를 대체하지 않고 보완합니다. - 수정 비용이 낮은 MR 단계에서 문제를 발견하는 것이 목적이며, GitLab 애플리케이션 보안팀도 내부 MR에 사용해 왔습니다. ## 변경 내용과 주변 맥락을 함께 분석 - MR의 diff뿐 아니라 다음 정보를 함께 검토합니다. - 원본 파일 - 변경된 코드 - MR 토론 내용 - 관련 코드 - 보안 엔지니어처럼 코드의 의도와 실행 흐름을 추론합니다. - 별도의 검증 단계가 각 발견 사항을 다시 점검해 오탐 가능성을 줄입니다. - 발견 결과는 관련 코드 라인의 diff 스레드와 내부 노트에 표시됩니다. - 퍼블릭 프로젝트에서는 보안 세부 정보가 외부에 노출되지 않도록 내부 노트에만 결과가 기록됩니다. ## 발견 사항과 MR 처리 방식 각 결과에는 다음 정보가 포함됩니다. - 취약점 유형과 CWE(Common Weakness Enumeration) 참조 - 심각도: Critical, High, Medium, Low - 분류 등급 - Tier 1: 악용 가능성이 높은 취약점 - Tier 2: 논리적 결함 - Tier 3: 설계 문제 - 문제에 대한 평이한 설명 - 가능한 경우 제공되는 수정 제안 심각도에 따라 MR 상태도 달라집니다. - Critical 또는 High: `Request changes` - Medium 또는 Low: `Comment` - 취약점이 발견되지 않아도 자동 승인하지 않으며, 최종 승인은 항상 사람이 담당합니다. 발견된 문제는 수정 제안 적용, 오탐으로 기각, 위험 수용 중 하나로 처리할 수 있습니다. 수정 후에는 새 검토를 요청해 변경 사항이 해결되었는지 다시 확인합니다. ## 도입 대상과 비용 - Security Review Flow는 GitLab Ultimate 고객을 위한 퍼블릭 베타 기능입니다. - GitLab.com, Self-Managed, Dedicated 환경에서 사용할 수 있습니다. - GitLab Duo Agent Platform 무료 체험 또는 Ultimate 구독에 포함된 GitLab Credits로 이용할 수 있습니다. - 비용은 diff의 복잡도와 선택한 모델에 따라 달라지므로, 전체 적용 전에 일부 MR에서 시험하는 것이 권장됩니다. - 베타 이후 가격은 변경될 수 있습니다. 실무에서는 기존 SAST·시크릿 스캐너를 계속 사용하면서, 인증·인가와 상태 전이가 복잡한 MR에 Security Review Flow를 추가하는 방식이 적절합니다. 특히 결제, 계정 권한, 개인정보, 멀티테넌트 데이터처럼 업무 규칙 위반의 영향이 큰 변경부터 적용하는 것이 효과적입니다.

gitlab

GitLab 패치 릴리스: 19.1.1, 19.0.3, 18.11.6 | GitLab 문서 (새 탭에서 열림)

2026년 6월 24일 GitLab은 19.1.1, 19.0.3, 18.11.6 패치 릴리스를 공개했으며, 여러 보안 취약점과 버그를 수정했다. 자체 호스팅 CE/EE 사용자는 즉시 지원 버전의 최신 패치로 업그레이드해야 하며, GitLab.com은 이미 패치가 적용되었다. GitLab Dedicated 고객은 별도 조치가 필요하지 않다. ## 패치 릴리스와 권고 사항 - 대상 버전: - GitLab 19.1.1 - GitLab 19.0.3 - GitLab 18.11.6 - Omnibus, 소스 설치, Helm 차트 등 배포 방식과 관계없이 취약 버전은 영향을 받을 수 있다. - GitLab은 정기적으로 매월 둘째·넷째 수요일에 패치 릴리스를 제공하며, 고위험 취약점에는 비정기 긴급 패치를 배포한다. - 보안 취약점의 상세 이슈는 패치 릴리스 후 30일이 지나면 공개된다. ## 분석 대시보드 XSS - **CVE-2026-10086**, CVSS 8.7. - GitLab EE의 Analytics Dashboard에서 사용자 입력 sanitization이 충분하지 않았다. - 인증된 Developer 권한 사용자가 다른 사용자의 세션 컨텍스트에서 임의의 클라이언트 측 코드를 실행할 수 있었다. - GitLab EE 16.4 이상 중 다음 버전 이전이 영향받는다. - 18.11.6 - 19.0.3 - 19.1.1 ## Web IDE 자산 처리기의 XSS - **CVE-2026-10712**, CVSS 8.0. - Web IDE workbench의 경로 검증 오류를 악용하면 인증되지 않은 공격자가 사용자의 브라우저 세션에서 임의의 JavaScript를 실행할 수 있었다. - GitLab CE/EE의 다음 버전 이전이 영향을 받는다. - 18.11.6 - 19.0.3 - 19.1.1 - 네트워크를 통한 공격이 가능하지만, 특정 조건과 사용자 상호작용이 필요하다. ## Duo Workflows 정보 노출 - **CVE-2026-12053**, CVSS 7.7. - GitLab EE의 Duo Workflows가 출력 내용을 충분히 필터링하지 못했다. - 조건에 따라 사용자가 프로젝트에 이미 커밋된 민감한 정보를 열람할 수 있었다. - GitLab EE 19.1 계열에서 19.1.1 이전 버전이 영향받는다. ## Virtual Registry 권한 우회 - **CVE-2026-5309**, CVSS 5.4. - Virtual Registry Cleanup Policy API의 권한 검사가 잘못되어 있었다. - 인증된 사용자가 다른 그룹의 가상 레지스트리 정리 정책을 읽거나 수정할 수 있었다. - GitLab EE 18.6 이상 및 19.x의 특정 이전 버전이 영향을 받는다. ## Rapid Diffs의 부적절한 권한 검사 - **CVE-2026-2238**, CVSS 5.3. - 공개 프로젝트에서 인증되지 않은 사용자가 비공개 이슈 참조를 볼 수 있었다. - GitLab CE/EE 17.5 이상 중 18.11.6, 19.0.3, 19.1.1 이전 버전이 대상이다. ## DAST 사이트 프로필 비밀정보 노출 - **CVE-2026-11379**, CVSS 5.3. - DAST 사이트 프로필 관리 기능의 권한 오류로 Developer 권한 사용자가 사이트 프로필의 비밀정보를 탈취할 수 있었다. - GitLab EE 13.11 이상부터 영향을 받으며, 각 유지보수 계열의 최신 패치 이전 버전이 취약하다. ## CI/CD API 로그 정보 노출 - **CVE-2026-8330**, CVSS 4.4. - CI/CD API 엔드포인트의 필터링 부족으로 민감한 정보가 애플리케이션 로그에 기록될 수 있었다. - GitLab CE/EE 9.3 이후의 오래된 버전부터 이번 패치 이전 버전까지 영향을 받는다. - 로그에 노출된 토큰이나 비밀값이 있다면 업그레이드와 함께 해당 자격 증명을 교체해야 한다. ## Snippets 콘텐츠 은닉 - **CVE-2026-1606**, CVSS 4.3. - Snippets의 입력값 검증 오류로 인증된 사용자가 콘텐츠를 숨겨 표시할 수 있었다. - GitLab CE/EE 14.8 이상 중 18.11.6, 19.0.3, 19.1.1 이전 버전이 영향받는다. ## Maven 패키지 보호 규칙 우회 - **CVE-2026-5952**, CVSS 4.3. - Maven Package Registry의 권한 검사 오류로 Developer 권한 사용자가 보호된 Maven 패키지 메타데이터를 덮어쓸 수 있었다. - GitLab CE/EE 17.11 이상 중 최신 패치 이전 버전이 영향을 받는다. ## 그룹 패키지 API 접근 제어 오류 - **CVE-2026-5796**, CVSS 4.3. - Package Registry가 비활성화된 프로젝트의 패키지 메타데이터를 Reporter 권한의 그룹 사용자가 열람할 수 있었다. - GitLab CE/EE 13.6 이상 중 18.11.6, 19.0.3, 19.1.1 이전 버전이 대상이다. ## 권장 대응 - 자체 호스팅 GitLab은 가능한 한 즉시 18.11.6, 19.0.3, 19.1.1 중 지원 중인 계열로 업그레이드한다. - 업그레이드 전 백업과 복구 절차를 확인하고, 업그레이드 후 CI/CD, Package Registry, Web IDE, DAST, Duo Workflows를 점검한다. - 로그나 설정에서 민감정보 노출 가능성이 확인되면 토큰·비밀번호·패키지 자격 증명을 함께 교체한다. - GitLab.com은 이미 수정 버전이 적용되어 별도 조치가 필요하지 않다.

line

ID-JAG The Hard Way: 실패로 배우는 AI 에이전트 보안 핸즈온 (새 탭에서 열림)

AI 에이전트의 API 접근에는 단순한 사용자 인증을 넘어, 에이전트가 특정 사용자를 대신해 정해진 범위의 작업만 수행하도록 통제하는 위임 인가가 필요하다. 글은 OAuth 기반 프로필인 ID-JAG를 활용해 Keycloak, Athenz, MCP 서버, 리소스 서버가 연계되는 전체 흐름을 로컬 핸즈온으로 재현한다. 특히 인증 정보와 실제 접근 권한을 분리하고, 기업 정책에 따라 실패 지점을 명확히 차단하는 중앙 집중형 인가 구조를 강조한다. ## ID-JAG가 해결하려는 문제 - ID-JAG는 다음 OAuth 표준을 결합해 위임된 크로스 도메인 API 접근을 지원한다. - OAuth 2.0 Token Exchange(RFC 8693) - JWT Profile for OAuth 2.0 Authorization Grants(RFC 7523) - 기존의 “사용자가 누구인가?”라는 인증 중심 질문을 다음과 같이 확장한다. - AI 에이전트가 현재 사용자를 대신해 특정 리소스에 접근할 권한이 있는가? - 요청된 권한 범위와 기업 정책을 충족하는가? - AI 에이전트에 영구적이고 포괄적인 권한을 주면 오작동이나 공격 시 피해 범위가 커지고, 사용자의 의도와 에이전트의 자율 행동을 구분하기 어렵다. - 모든 API 호출마다 사용자의 동의를 요구하면 자동화와 사용자 경험이 훼손된다. - ID-JAG는 임시 토큰 연결 대신, 정책에 기반한 명시적 위임과 중앙 집중형 신뢰 관계를 제공한다. ## 데모 아키텍처와 역할 분리 핸즈온에서는 인증과 인가 정책을 의도적으로 분리한다. - **Keycloak** - 사용자를 인증하는 업스트림 IdP다. - 로그인 결과로 원본 ID 어서션을 발급한다. - **Athenz** - KeycloakTokenExchangePlugin을 통해 연동된 IdP 인가 서버로 동작한다. - Keycloak 토큰의 발급자, 서명, 대상, 주체, 클라이언트 바인딩을 검증한다. - 기업 정책을 평가하고 최종 ID-JAG 어서션을 발급한다. - 중앙 리소스 인가 서버이자 정책 결정 지점(PDP) 역할을 한다. - **AI 에이전트** - 사용자를 대신해 ID-JAG와 액세스 토큰을 요청한다. - 장기 마스터 키가 아니라 정책으로 제한된 임시 권한을 사용한다. - **MCP 서버** - 에이전트가 호출하는 보호된 중간 리소스 서버다. - 전달받은 토큰을 인가 서버와 교환한 뒤 최종 리소스 서버에 접근한다. - **리소스 서버** - Athenz가 발급한 신뢰 가능한 토큰만 수용한다. - 업스트림 IdP의 토큰을 무조건 인가 그랜트로 인정하지 않는다. ## ID-JAG 실행 흐름 실습 환경에서는 다음 순서로 위임 접근이 진행된다. - 사용자가 Keycloak을 통해 로그인한다. - 사용자가 AI 에이전트에 작업을 지시한다. - 에이전트가 Athenz에 ID-JAG 토큰을 요청한다. - Athenz가 사용자, 클라이언트, 대상 리소스, 권한 범위 및 기업 정책을 검증한다. - 허용된 경우 에이전트가 Athenz에 액세스 토큰을 요청한다. - 에이전트가 액세스 토큰을 포함해 MCP 서버를 호출한다. - MCP 서버가 토큰 교환을 수행한다. - 교환된 토큰으로 최종 리소스 서버에 요청한다. 이 구조에서는 인증된 사용자라는 사실만으로 모든 리소스 접근이 허용되지 않으며, 각 단계에서 위임 범위와 정책을 다시 확인한다. ## 인증 토큰과 인가 그랜트의 분리 Keycloak의 ID 토큰을 곧바로 액세스 토큰으로 교환하는 방식도 기술적으로는 가능하지만, 보안 모델상 한계가 있다. - **ID 토큰** - 사용자가 클라이언트에 성공적으로 인증됐음을 나타낸다. - 특정 리소스에 접근할 권리를 직접 의미하지 않는다. - **인가 그랜트** - 특정 리소스와 권한 범위에 대한 액세스 토큰 발급을 요청하기 위해 인가 서버에 제출된다. - ID-JAG를 별도의 인가 그랜트로 사용하면 다음 실패 유형을 구분할 수 있다. - 사용자 인증 실패 - 그랜트 검증 실패 - 에이전트 위임 거부 - 기업 정책 거부 - 리소스 서버의 토큰 거부 - 이 경계는 장애 분석과 감사 추적을 명확하게 만들고, 로그인 성공이 곧 크로스 도메인 API 접근 권한으로 오해되는 것을 방지한다. ## 실패 경로를 통한 보안 검증 핸즈온은 정상 동작뿐 아니라 의도적인 설정 오류를 통해 정책 경계를 확인하도록 구성된다. - 토큰 없이 보호된 API를 호출하면 `401 Unauthorized`가 발생한다. - 엔터프라이즈 역할만 설정하고 멤버십을 누락하면 토큰 교환이 실패한다. - 에이전트에 필요한 위임 권한을 부여하지 않으면 위임 호출이 차단된다. - 각 오류는 인증, 역할, 멤버십, 위임 정책, 토큰 교환 중 어느 단계가 필요한지 보여준다. - Athenz UI에서 에이전트의 위임 권한을 제거한 뒤 다시 실행하면 차단이 발생하는 지점을 직접 추적할 수 있다. ## 중앙 정책 관리의 장점 - 기업의 위임 정책을 Athenz 한 곳에서 관리할 수 있다. - 여러 IdP, SaaS, 리소스 애플리케이션에 정책을 중복 배포할 필요가 줄어든다. - 벤더별 인가 로직에 대한 종속을 완화할 수 있다. - 시스템 간 정책 불일치와 운영상의 보안 위험을 줄인다. - Athenz가 ID-JAG 발급자이자 PDP로 기능하면서, 위임 API 접근에 대한 단일 진실 공급원이 된다. ## 실습 방법과 권장 사항 - `athenz-community/id-jag-the-hard-way` 저장소에서 튜토리얼을 실행한다. - 정상 흐름뿐 아니라 의도적으로 역할, 멤버십, 위임 권한을 제거해 실패 지점을 확인하는 것이 중요하다. - 실제 기업 환경에서는 인증 성공 여부와 별도로 리소스·권한·에이전트·정책을 명시적으로 검증해야 한다. - AI 에이전트 도입 시 장기 자격 증명 대신 제한된 범위의 단기 토큰과 중앙 정책 평가를 사용하는 방식을 권장한다.

figma

대규모 가시성: Figma가 (새 탭에서 열림)

피그마(Figma)는 서비스 규모가 확장됨에 따라 복잡해진 권한 관리 로직을 효율적으로 처리하기 위해 자체적인 권한 정의 언어(DSL)인 'Permit'을 구축했습니다. 기존의 파편화된 명령형 코드 방식에서 벗어나 선언적인 DSL을 도입함으로써 권한 정책의 일관성을 확보하고 보안 취약점 발생 가능성을 획기적으로 낮췄습니다. 이를 통해 복잡한 사용자-리소스 간의 관계를 명확하게 모델링하고 성능 저하 없이 대규모 시스템에 적용할 수 있는 권한 검증 인프라를 완성했습니다. ### 기존 시스템의 한계와 권한 관리의 복잡성 * 권한 체크 로직이 Go 애플리케이션 코드 곳곳에 흩어져 있어, 특정 리소스에 대한 접근 규칙을 한눈에 파악하거나 일관되게 수정하기 매우 어려웠습니다. * 팀, 프로젝트, 파일로 이어지는 계층 구조뿐만 아니라 엔터프라이즈 설정, 공유 링크 등 수많은 변수가 결합되면서 권한 로직 수정 시 예기치 않은 부작용(side effects)이 발생할 위험이 컸습니다. * 성능 최적화를 위해 데이터베이스 쿼리에 권한 로직을 직접 포함시켜야 하는 경우가 많았는데, 이는 비즈니스 로직과 권한 정책이 뒤섞여 코드 유지보수성을 떨어뜨리는 결과로 이어졌습니다. ### 관계 기반 접근 제어(ReBAC)와 Permit DSL 설계 * 구글의 Zanzibar 시스템에서 영감을 얻어, 객체 간의 관계를 중심으로 권한을 정의하는 ReBAC(Relationship-Based Access Control) 모델을 피그마의 환경에 맞게 커스텀화했습니다. * Permit DSL은 'Actor(사용자)', 'Resource(파일, 팀 등)', 'Action(편집, 보기 등)' 간의 관계를 선언적인 문법으로 정의합니다. * 예를 들어 "사용자가 파일이 속한 프로젝트의 편집자라면 해당 파일에 대한 편집 권한을 가진다"와 같은 전이적인(transitive) 관계를 직관적인 문법으로 표현할 수 있게 되었습니다. ### 컴파일러 및 성능 최적화 기술 * DSL로 작성된 정책을 런타임에 해석하는 대신, 효율적인 Go 코드로 변환하는 자체 컴파일러를 개발하여 실행 성능을 극대화하고 런타임 오버헤드를 최소화했습니다. * 컴파일 단계에서 정적 분석을 수행하여 순환 참조나 정의되지 않은 권한 사용 등 논리적 오류를 사전에 차단합니다. * 특히 '부분 평가(Partial Evaluation)' 기법을 도입하여, 권한 로직을 SQL 쿼리의 WHERE 절로 변환함으로써 수백만 개의 리소스 중 사용자가 접근 가능한 항목만 효율적으로 필터링할 수 있도록 구현했습니다. ### 안전한 전환을 위한 검증 및 배포 프로세스 * DSL 내부에 유닛 테스트를 직접 작성할 수 있는 기능을 포함시켜, 정책 변경이 기존의 기대 결과와 일치하는지 배포 전 즉시 검증할 수 있는 환경을 마련했습니다. * '섀도 모드(Shadow mode)'를 활용하여 실제 트래픽에서 기존의 레거시 권한 로직 결과와 새로운 Permit 시스템의 결과를 실시간으로 비교하며 데이터 정합성을 확인했습니다. * 성능 모니터링을 통해 권한 확인 작업이 전체 API 응답 시간에 미치는 영향을 정밀하게 추적하며 안정성을 확보했습니다. 권한 관리는 단순한 기능을 넘어 대규모 SaaS의 보안과 확장성을 결정짓는 핵심 인프라입니다. 피그마의 사례처럼 권한 로직을 비즈니스 코드에서 분리하여 '정책(Policy)'으로서 중앙 집중화하고 코드화하는 전략은, 제품의 복잡도가 높아질수록 개발 생산성과 시스템 안정성을 동시에 잡을 수 있는 가장 강력한 방법 중 하나입니다.

figma

Figma에서 커스텀 권한 (새 탭에서 열림)

Figma는 기존 Ruby 모놀리스의 `has_access?` 메서드에 모든 권한 로직을 집중시킨 결과, 복잡성·디버깅 난이도·계층형 권한의 한계·데이터베이스 부하 문제에 직면했다. 이를 해결하기 위해 자체 권한 도메인 특화 언어(DSL), 크로스플랫폼 권한 로직 엔진을 구축하고 핵심 권한 규칙을 새 시스템으로 이전했다. 목표는 권한 정확성과 성능을 높이는 동시에 개발자가 안전하게 권한 규칙을 변경할 수 있도록 만드는 것이었다. ## Figma의 권한 모델 - Figma의 협업 기능은 파일과 폴더, 팀, 조직 단위의 복잡한 권한 구조를 필요로 한다. - 파일 접근 방식은 크게 두 가지다. - **역할 기반 접근**: 상위 폴더·팀·조직에서 상속된 역할에 따라 접근한다. - **링크 기반 접근**: 링크를 가진 사용자의 접근 수준, 만료 기간, 비밀번호, 조직 정책 등을 조합해 결정한다. - 파일 삭제 여부, 계층 구조, 조직 제한, 결제 상태 등도 접근 가능 여부에 영향을 준다. - 기존에는 각 ActiveRecord 모델의 `has_access?` 메서드가 사용자와 리소스를 받아 접근 가능 여부를 boolean으로 반환했다. ## 기존 `has_access?` 방식의 한계 - 권한 판단에 필요한 모든 비즈니스 로직이 하나의 긴 메서드에 들어갔다. - 제품 엔지니어가 컨트롤러에서 이 메서드를 적절한 시점에 직접 호출해야 했다. - 작은 변경도 전체 권한 체계에 영향을 줄 수 있어 개발자들이 메서드 수정 자체를 꺼리게 됐다. - 권한 버그는 Figma의 모든 파일에 대한 접근 허용으로 이어질 수 있어 위험성이 컸다. - 디버깅 시 특정 규칙만 분리해 확인하기 어려웠고, 수십 개의 로그를 코드 곳곳에 추가해야 했다. ## 계층형 권한과 boolean 플래그의 문제 - 권한 수준을 정수로 표현했지만, 실제 동작은 여러 boolean 플래그에 의해 달라졌다. - 예시 메서드는 다음과 같은 선택적 인자를 포함했다. - `ignore_link_access` - `org_candidate` - `ignore_archived_branch` - 같은 권한 수준이라도 플래그 조합에 따라 결과가 달라져 개발자가 이해해야 할 경우의 수가 많았다. - 리소스마다 플래그의 의미와 동작이 달라 일관된 권한 모델을 만들기 어려웠다. - 예를 들어 `300` 수준의 편집 권한은 있어도, 특정 조건을 무시한 `100` 수준의 보기 권한 검사는 통과하지 못할 수 있었다. - 따라서 기존 계층 구조만으로는 표현하기 어려운, 서로 독립적인 세밀한 권한이 필요했다. - 새로운 시스템은 기존 계층형 권한을 지원하면서도 비계층적이고 독립적인 권한 체계를 추가할 수 있어야 했다. ## 권한 검사로 인한 데이터베이스 부하 - Figma의 사용자와 리소스 규모가 빠르게 증가하면서 권한 검사가 데이터베이스에 큰 부담을 줬다. - 전체 데이터베이스 부하 중 약 **20%**가 권한 검사에서 발생했다. - 데이터베이스를 수직·수평 확장하는 것만으로는 물리적 한계가 있었기 때문에, 권한 로직 자체가 데이터 계층에 가하는 부하를 줄여야 했다. - 새로운 권한 시스템에는 권한 데이터를 어떻게 조회하고 처리할지에 대한 더 세밀한 제어가 필요했다. ## 자체 권한 DSL과 로직 엔진 - Figma는 외부 솔루션을 우선 검토하는 일반적인 방침과 달리, 권한 문제에는 자체 시스템을 선택했다. - 구축한 구성 요소는 다음과 같다. - 권한 규칙을 명확하게 표현하는 **도메인 특화 언어(DSL)** - 여러 환경에서 동작하는 **크로스플랫폼 권한 로직 엔진** - 기존의 핵심 권한 규칙을 새 시스템으로 이전하는 마이그레이션 체계 - 이를 통해 권한 규칙을 하나의 거대한 조건문으로 관리하지 않고, 독립적이고 조합 가능한 규칙으로 다룰 수 있게 하는 것이 목표였다. - 결과적으로 권한 로직을 제품 기능과 분리하고, 규칙 추가·수정·삭제 시 기존 권한 체계를 모두 다시 이해해야 하는 부담을 줄이려 했다. ## 실용적인 결론 복잡한 권한 시스템에서는 단순한 `if/else` 함수와 호출 규약만으로 규모 확장을 감당하기 어렵다. 권한을 독립적인 규칙으로 모델링하고, 선언적인 DSL과 공통 실행 엔진을 사용하면 정확성·성능·개발자 경험을 함께 개선할 수 있다.