위임된 액세스

사용자에게 필요한 정확한 권한만 부여하세요. 그 이상은 안 됩니다.

개발자를 참여시키고, 회계 담당자에게 청구 권한을 넘기며, 클라이언트에게는 자신의 사이트를 볼 수 있는 읽기 전용 권한을 부여하거나, 지원 팀이 문제를 확인할 수 있도록 하세요. 모든 권한 부여는 정의된 권한을 가진 역할이며, 조직 단위로 적용되고, 데이터베이스에서 강제되며, 추가 전용 감사 로그에 기록됩니다.

  • 94세부 권한
  • 12내장 역할
  • 8직원 부서
  • 650,000개 이상전 세계에서 호스팅되는 사이트

공유된 비밀번호가 아니라, 액세스는 멤버십입니다.

하나의 로그인 정보를 공유하는 것은 계정 액세스 문제를 일으키는 원인입니다. Zinn Digital®에서는 모든 사람이 각자의 아이덴티티를 가지며, 액세스는 개별적으로 부여, 변경 또는 취소할 수 있는 사용자, 조직, 역할로 구성된 멤버십입니다.

귀하의 신원, 항상

Zinn Digital®의 신원 확인 계층인 Keycloak을 통해 각 공동 작업자가 본인 명의로 로그인합니다. 그 누구도 귀하의 비밀번호를 입력하거나 브라우저 세션을 공유하지 않으며, 특정 사용자를 제외하는 작업은 비밀번호를 변경하고 다른 누가 그 비밀번호를 알고 있었는지 알아내기 위해 허둥지둥할 필요 없이 단 한 번의 조치로 처리됩니다.

조직은 트리 구조를 형성합니다

계정은 계층 구조로 이루어져 있습니다. 즉, 리셀러 조직은 클라이언트 조직을 보유하고, 클라이언트 조직은 사이트를 보유합니다. 멤버십은 조직과 그 하위의 모든 항목에 적용되므로, 다른 클라이언트를 전혀 노출하지 않고도 대행사 클라이언트에게 자신의 조직에 대한 제어권을 부여할 수 있습니다.

데이터베이스에서 격리가 적용되었습니다

테넌트 분리는 버그로 인해 우회될 수 있는 애플리케이션 코드 레벨의 필터가 아닙니다. Postgres 행 수준 보안(Row-Level Security)은 모든 쿼리를 호출자의 조직 하위 트리로 한정하므로, 허용된 범위를 벗어난 요청은 반환할 데이터가 아예 존재하지 않습니다.

부재는 보이지 않습니다

조직이나 사이트가 작업 범위 외에 있는 경우, 권한 오류 대신 일반적인 '찾을 수 없음' 응답을 반환합니다. 권한 오류는 해당 레코드가 존재함을 확인시켜 주지만, '찾을 수 없음'은 외부 사용자에게 아무런 정보도 노출하지 않습니다.

네 가지 고객 역할, 서른다섯 가지 권한

권한은 모듈과 작업의 조합으로 이루어진 세밀한 키(예: sites.restart 또는 billing.refund)이며, 역할은 이를 묶어줍니다. 네 가지 역할은 실제 팀에 필요한 형태를 아우르며, 각각은 코드에 숨겨진 로직이 아니라 기본으로 제공되는 데이터입니다.

소유자

전체 제어 권한: 하위 조직 생성, 멤버 초대 및 제거, 역할 변경, API 키 관리, 사이트 생성·재시작·퍼지·정지 및 삭제, 청구 및 인보이스 관리, 티켓 생성, 감사 로그 조회. 본인이 보유하게 될 역할입니다.

빌링 관리자

조직, 구성원, 요금제 카탈로그를 조회하고 인보이스, 결제 수단, 청구를 관리합니다. 단일 사이트를 생성, 변경 또는 삭제할 수 있는 권한은 없습니다. 외부 경리 담당자에게 정확히 필요한 권한입니다.

개발자

사이트를 조회 및 생성하고, 서비스를 재시작하며, 캐시를 지우고, API 키를 관리하며, 티켓을 처리합니다. 제외된 항목: 결제, 청구서, 결제 수단, 회원 관리, 사이트 일시 중지 및 사이트 삭제. 계약자는 요금을 청구하거나 무언가를 파괴할 권한 없이 개발을 수행할 수 있습니다.

읽기 전용

조직, 구성원, 사이트, 청구, 요금제 카탈로그, 티켓, 번역 상태 및 감사 로그를 볼 수 있지만 그중 어느 것도 변경할 수 없습니다. 가시성을 원하는 고객, 감사자 또는 조회만 필요한 이해관계자에게 적합한 권한입니다.

팀의 로그인 설정을 무단으로 완화할 수 없습니다

액세스 위임은 위임하는 계정을 탈취하기 어려운 경우에만 안전합니다. 계정의 모든 사용자에 대해, 모든 인터페이스에서 Keycloak을 통해 인증이 실행됩니다.

  • 피싱에 안전한 로그인을 위한 패스키와 WebAuthn, 그리고 팀원이 건너뛸 수 있는 선택적 설정이 아니라 정책에 따라 모든 사용자에게 강제되는 TOTP 2단계 인증.
  • 기본 로그인 방식인 매직 링크 이메일 로그인을 제공하며, 대체 수단으로 이메일 및 비밀번호 로그인, 그리고 Google, Microsoft, GitHub 등을 통한 소셜 로그인을 지원합니다.
  • 기업 및 에이전시 고객을 위한 SAML 싱글 사인온을 통해 신규 입사자와 퇴사자의 관리가 수동 방식 대신 아이덴티티 제공자(IdP)를 통해 자동으로 이루어집니다.
  • 고객 대시보드, 공개 사이트 및 지식 베이스, 그리고 지원 티켓을 아우르는 단 하나의 세션—한 번 로그인하고 한 번에 해제하세요.
  • 세션 정책, 민감한 작업에 대한 단계별 인증, 그리고 알려진 네트워크로 접근을 제한하려는 계정을 위한 선택적 조직별 IP 허용 목록입니다.
  • 모든 가입 이메일은 계정이 생성되기 전에 검증되므로, 반송되거나 일회용 또는 역할 기반 주소는 나중에 방치된 회원이 되는 대신 애초에 차단됩니다.

저희 팀이 액세스해야 할 때는 권한 범위가 지정되고 기록됩니다.

지원 업무를 진행하다 보면 계정 내부를 들여다봐야 하는 경우가 있습니다. 해당 액세스 권한은 다른 모든 기능과 마찬가지로 동일한 권한 모델의 적용을 받으며, 직원들은 단순히 제한된 권한이 부서별로 부여된 직원 조직에 소속되어 있습니다.

부서, 일괄 관리가 아님

직원은 지원, 청구 및 재무, 남용 및 신뢰 안전, 영업, 온보딩, 엔지니어링 및 운영, 마케팅, 그리고 경영으로 그룹화됩니다. 각 역할에는 특정 모듈과 권한이 부여되므로, 상담원은 관리자 콘솔에서 자신의 업무에 필요한 부분만 볼 수 있고 나머지는 볼 수 없습니다.

지원 상담원의 진정한 한계

지원 상담원 역할은 정확히 다음 권한을 부여합니다: 고객 조회, 티켓 조회 및 회신, 사이트 조회, 사이트 재시작, 캐시 삭제. 이 역할에는 결제 설정, 환불, 플랜 수정, 인프라 관리 권한이 포함되지 않습니다. 상담원이 수행할 수 있는 조치는 선의가 아니라 역할에 의해 제한됩니다.

고객으로 로그인하는 것은 엄격하게 제한됩니다

customer.impersonate 권한은 매니저 역할에 포함되지 않으며 슈퍼 관리자만 보유합니다. 대행 세션이 실행 중인 동안에는 대시보드에 지속적인 대행 배너가 표시되므로 누가 작업을 수행 중인지 항상 명확하게 알 수 있습니다.

특권을 가진 모든 것은 기록된다

모든 권한 및 관리 작업은 행위자, 작업, 대상, 관련 메타데이터, IP 주소 및 타임스탬프를 기록하는 추가 전용 감사 로그에 추가됩니다(프로덕션 환경에서는 시간별로 파티셔닝됨). 소유자와 읽기 전용 멤버는 조직의 로그를 직접 읽을 수 있습니다.

파괴적인 작업에 대한 승인 단계

민감하고 파괴적인 직원 작업은 실행하기 전에 추가 인증이나 2인 승인이 필요할 수 있으며, 새로운 부서와 역할은 코드 변경이 아니라 설정으로 처리됩니다.

머신에게도 위임된 권한이 부여됩니다

스크립트, CI 파이프라인, CLI, Terraform 프로바이더 및 AI 에이전트는 사람과 동일한 권한 모델을 통해 인증됩니다. 공유되는 사람 계정 자격 증명도 없고, 빌드에 붙여넣는 수명이 긴 보안 비밀도 없습니다.

API 키는 조직별로 생성되며 권한 범위가 지정됩니다.

키는 세분화된 범위가 지정된 조직에 속하며, 읽기 전용, 결제, 프로비저닝과 같은 동일한 RBAC 권한에 연결됩니다. 멤버의 전체 계정 대신 파이프라인에 필요한 최소한의 범위만 부여하세요.

샌드박스 키는 프로덕션과 분리되어 있습니다.

테스트 모드와 라이브 모드의 키는 서로 구별되므로, 개발 중인 연동이 복사된 환경 변수나 실수로 인해 프로덕션 데이터에 접근할 수 없습니다.

해시만 저장됩니다

우리는 비밀 키 자체 대신 SHA-256 해시와 조회 접두사만 저장합니다. 키는 생성 시 한 번만 표시됩니다. 각 키는 마지막으로 사용된 시점을 추적하며, 다른 항목에 영향을 주지 않고 개별적으로 해지할 수 있습니다.

AI 도구는 회원님의 권한 하에 연결됩니다

당사의 MCP 서버를 사용하면 MCP 호환 에이전트가 자연어로 호스팅을 관리할 수 있습니다. OAuth 2.1로 인증되고 조직 및 RBAC 역할로 범위가 지정되며, 도구별 취소 가능한 토큰, 파괴적 작업에 대한 확인, 지출 한도 및 전체 감사 로깅이 제공됩니다.

사이트 자체에 대한 액세스

계정 액세스와 서버 액세스는 별개의 문제입니다. 사이트 수준의 자격 증명은 대시보드에서 관리되며, 최소 권한 원칙에 따라 발급되고 격리되어 한 협업자의 셸은 정확히 하나의 사이트 셸로만 제한됩니다.

  • 격리된 셸(jailed shell)을 지원하는 SSH와 SFTP 및 FTP — CageFS 격리를 통해 각 테넌트는 자신의 파일만 볼 수 있습니다.
  • 패널 터미널과 SSH를 통한 wp-cli 지원으로, 개발자가 실제로 스크립트화하고 싶어 하는 작업을 수행할 수 있습니다.
  • code-server를 통한 브라우저 내의 완전한 VS Code 편집기 — 확장 프로그램, 통합 터미널 및 git, 대시보드에서 사이트 파일을 직접 편집합니다.
  • phpMyAdmin 및 Adminer 데이터베이스 관리 도구와 파일 관리자가 대시보드에서 싱글 사인온(SSO)으로 통합되어 있어, 별도의 추가 로그인 정보 없이 바로 이용할 수 있습니다.
  • 대시보드에서 액세스 키와 자격 증명이 생성, 조회, 갱신 및 해지되며, 최소 권한으로 발급되고 사용 내역은 감사 로깅됩니다.
  • 클론 및 라이브 푸시 기능이 포함된 스테이징을 사용하면 위험한 작업이 프로덕션 환경에 영향을 주지 않으므로, 새로운 공동 작업자의 첫 번째 변경 사항이 라이브 사이트에 곧바로 반영되지 않습니다.

실제 업무 방식에 맞게 액세스 구조를 설계하는 방법

1인 운영자는 단일 조직과 하나의 소유자 멤버십을 유지하며, 계약직 직원이 프로젝트에 투입될 때 개발자 역할을 추가합니다. 프로젝트가 끝나면 멤버십이 제거되고 로그인이 즉시 중단되므로, 교체해야 할 공유 자격 증명이 남지 않습니다.

에이전시는 조직 트리를 사용합니다. 각 클라이언트는 해당 클라이언트의 사이트를 보유하는 자체 하위 조직을 갖고, 가시성을 원하는 이해관계자에게는 읽기 전용으로, 직접 관리를 원하는 클라이언트에게는 소유자 권한으로 해당 조직에 대한 멤버십이 부여됩니다. 귀사의 직원은 트리 상위에 멤버십을 보유하여 포트폴리오를 볼 수 있으며, 클라이언트는 자신의 지점만 볼 수 있고, 행 수준 보안(Row-Level Security)은 이것이 약속이 아닌 진실이 되도록 만듭니다.

리셀러도 한 단계 위에서 이와 동일한 방식으로 작동합니다. 즉, 리셀러 조직은 각각 고유한 회원, 청구 뷰 및 사이트를 갖춘 클라이언트 조직들을 보유하게 됩니다. 동일한 기본 요소가 서브 아카운트, 대행사 팀, 리셀러 계층 구조를 구동하며, 이 중 어느 것에도 별도의 열등한 메커니즘은 존재하지 않습니다.

카드 등록이 필요 없는 14일 무료 체험 기간 동안 모든 기능을 이용하실 수 있습니다. 결제 정보 없이 가입하고, 동료를 초대하고, 각 역할별로 접근 가능한 권한과 제한 사항을 확인하며, 직접 감사 로그(audit log)를 검토해 보세요.

자주 묻는 질문

특정 사이트 하나에만 대한 액세스 권한을 다른 사람에게 부여할 수 있나요?

현재 멤버십은 조직 전체와 그 하위의 모든 항목에 권한을 부여하므로, 사이트 그룹을 분리하는 방법은 조직을 분리하는 것, 즉 해당 사이트들을 자체 하위 조직에 넣고 그곳에 멤버십을 부여하는 것입니다. 이는 각 클라이언트가 이미 자신만의 경계를 원하는 에이전시와 리셀러에게 깔끔한 모델입니다. 멤버십별 리소스 범위 지정, 즉 단일 멤버십을 한 조직 내의 지정된 사이트에 고정하는 기능은 현재 사용할 수 있는 기능이 아니라 향후 개선될 예정인 기능입니다.

초대된 개발자가 사이트를 삭제하거나 라이브 환경에 배포할 수 있나요?

개발자 역할에는 사이트 삭제나 사이트 일시 중지 권한이 포함되어 있지 않으며, 해당 권한은 소유자 역할에 속합니다. 이 역할은 사이트 조회 및 생성, 서비스 재시작, 캐시 삭제, API 키 관리 및 티켓 처리 권한을 부여합니다. 배포 및 라이브 푸시 권한 역시 개발자 권한에 포함되지 않으므로, 프로덕션 승격은 계정 소유자에게 남겨집니다. 이를 스테이징과 결합하면 빌드 작업이 라이브 사이트가 아닌 곳에서 먼저 이루어지게 됩니다.

Zinn Digital® 직원은 내 계정에서 어떤 항목을 볼 수 있나요?

직원 역할에 따라 완전히 달라지며, 각 역할은 제한된 권한 키 집합으로 구성됩니다. 예를 들어, 지원 상담원(Support Agent)은 계정과 사이트를 조회하고, 티켓을 조회 및 답변하며, 사이트를 재시작하고 캐시를 비울 수 있지만, 결제 설정, 환불, 요금제 또는 플릿(fleet)은 건드릴 수 없습니다. 고객으로 로그인하는 기능은 슈퍼 관리자(Super Admin)만 보유한 별도의 권한이며, 이 기능이 실행되면 대시보드에 지속적인 대행(impersonation) 배너가 표시됩니다. 모든 권한 작업은 주체, 작업, 대상, IP 및 타임스탬프와 함께 감사 로그에 기록되며, 조직의 로그를 직접 확인할 수 있습니다.

퇴사자가 발생했을 때 어떻게 액세스 권한을 신속하게 취소하나요?

멤버십을 삭제하면 해당 조직에 대한 접근 권한이 종료됩니다. 그들은 자신의 계정을 유지하지만 역할과 권한이 없어지므로 귀하의 계정에서 아무런 권한을 갖지 못합니다. API 키는 개별적으로 취소되므로 다른 요소에 영향을 주지 않고 파이프라인 키를 중단할 수 있습니다. SAML 싱글 사인온(SSO)을 사용하는 경우, ID 공급자(IdP)에서 프로비저닝을 해제하여 로그인을 중앙에서 관리할 수 있습니다. SSH 키와 같은 사이트 수준 자격 증명은 대시보드에서 취소되며, 삭제 작업 자체는 감사 로그에 기록됩니다.

팀원들이 내 API 키를 공유하나요?

아니요 — 하지만 그 이유를 정확히 이해할 필요는 있습니다. API 키는 개인이 아니라 조직에 속하며, 동일한 권한 카탈로그에 연결된 고유한 세부 범위(scope)를 가집니다. 따라서 개인에게 키를 직접 전달하는 대신, 해당 작업에 필요한 가장 제한된 범위로 작업을 수행할 키를 생성하고 작업이 끝나면 해당 키를 폐기합니다. 시크릿의 해시값만 저장되며, 각 키는 마지막으로 사용된 시점을 기록하므로 사용되지 않는 키를 쉽게 찾아 폐기할 수 있습니다.

모든 권한을 넘겨주지 않고도 AI 에이전트를 연결할 수 있나요?

네. 당사의 MCP 서버는 OAuth 2.1을 통해 에이전트를 인증하고 사용자 조직 및 RBAC 역할에 권한 범위를 한정하며, 도구별로 철회 가능한 토큰을 사용하므로 일괄적인 전체 액세스 권한 대신 특정 기능만을 부여할 수 있습니다. 파괴적인 작업에는 확인이 필요하고 지출 한도가 적용되며, 모든 작업은 인간의 활동과 동일한 감사 로그에 기록됩니다.

한 테넌트가 다른 테넌트의 데이터에 접근하는 것을 무엇이 막나요?

포스트그레스(Postgres) 행 수준 보안은 데이터베이스 자체에서 호출자의 조직 하위 트리로 쿼리 범위를 제한하며, 애플리케이션 수준의 필터는 유일한 방어선이 아닌 심층 방어 역할을 합니다. 범위를 벗어난 레코드에 대한 요청은 권한 오류 대신 찾을 수 없음(not-found)을 반환하므로 존재하는 것에 대해 어떠한 정보도 노출되지 않습니다. 서버 측에서는 CageFS를 통한 사이트별 격리를 통해 각 테넌트의 쉘과 파일이 자신의 사이트에만 유지되도록 합니다.

결제하기 전에 체험해 볼 수 있나요?

네. 14일 체험판은 카드 등록이 필요 없으며(결제 정보 없음, 약정 없음), 최대 5개의 사이트를 포함하는 Footprint-Free Hosting을 지원합니다. 동료를 초대하고, 역할을 할당하고, 정식 계약 전에 경계가 필요한 대로 작동하는지 확인하기에 충분합니다.

눈으로 확인할 수 있는 경계와 함께 권한을 위임하세요

카드 등록 없는 14일 무료 체험을 시작하고, 팀원을 초대하여 권한 모델이 어떻게 작동하는지 직접 확인해 보세요. 이름을 지정할 수 있는 역할, 취소 가능한 범위, 그리고 정확히 누가 무엇을 했는지 기록하는 감사 로그를 경험할 수 있습니다.

무료로 시작하기