---
title: "인증 및 접근 제어"
description: "Alpacon의 로그인과 접근 제어 방식을 설명합니다. MFA와 SSO를 설정할 때 확인할 사항을 살펴보고, 사용자와 그룹, 작업 세션의 범위가 서버 접근에 어떤 영향을 주는지 알아보세요. 민감한 작업에서 추가 인증이 필요한 경우와 관련 설정 가이드도 확인할 수 있습니다."
---

> Full documentation index: https://docs.alpacax.com/llms.ko.txt

# 인증 및 접근 제어

Alpacon은 권한이 있는 사용자만 인프라에 접근하도록 견고한 인증·접근 제어 체계를 갖추고 있습니다.

## 인증 인프라

Alpacon Cloud는 인증 제공업체로 **Auth0 by Okta**를 사용해 엔터프라이즈급 보안과 신뢰성을 확보합니다.

### Auth0를 사용하는 이유

- **업계 선도**: Auth0(Okta 인수)는 수천 개의 기업이 사용하는 신뢰받는 신원 플랫폼
- **인증된 보안**: SOC 2 Type II, ISO 27001 및 PCI DSS 인증
- **컴플라이언스 준비**: GDPR, HIPAA 및 기타 규제 요구사항 지원
- **높은 가용성**: Okta가 운영하는 글로벌 인프라
- **지속적인 보안**: Okta 보안 팀의 정기적인 보안 감사 및 업데이트
- **고급 위협 탐지**: 자격 증명 스터핑, 무차별 대입 공격 및 비정상적인 로그인 패턴에 대한 내장 보호

### Alpacon 사용자를 위한 이점

Alpacon은 Auth0를 기반으로 다음을 제공합니다:

- **검증된 보안**: Fortune 500 기업이 사용하는, 실전에서 검증된 인증
- **투명한 신뢰**: Auth0의 보안 인증 및 컴플라이언스 보고서는 공개적으로 제공됨
- **신속한 보안 업데이트**: 새로 발견된 인증 취약점에 대한 즉각적인 보호
- **풍부한 기능**: 고급 인증 기능(MFA, SSO, 적응형 인증)을 사용 가능
- **신뢰성**: 지리적 중복성 및 자동 페일오버로 인증이 항상 사용 가능

> **보안 참고**: Alpacon은 인증을 위해 Auth0를 사용하지만, 권한 부여 및 접근 정책에 대한 완전한 제어를 유지합니다. Auth0는 "누구인가"(인증)를 확인하고, Alpacon은 "무엇을 할 수 있는가"(권한 부여)를 제어합니다.

## 인증 방법

### 이메일 및 비밀번호

Alpacon Cloud에서 로그인은 Auth0가 처리합니다:

- **이메일/비밀번호 로그인**: 이메일과 비밀번호를 사용한 인증
- **비밀번호 저장 및 보호**: 비밀번호는 Alpacon이 아니라 Auth0가 저장하고 검증합니다. Auth0는 무차별 대입과 자격 증명 스터핑 방어, 유출된 비밀번호 탐지를 제공합니다.

### 다중 인증(MFA)

MFA는 사용자 계정에 보안 계층을 한 겹 더합니다:

#### 지원되는 MFA 방법

Alpacon은 다음 MFA 방법을 지원합니다(워크스페이스에서 허용 방법을 제한할 수 있습니다):

- **하드웨어 보안 키**: YubiKey 같은 WebAuthn 호환 키. 피싱에 강하고 가장 강력합니다.
- **생체 인증 (FaceID, 지문)**: 기기에 내장된 생체 센서. 생체 데이터는 기기를 떠나지 않습니다.
- **일회용 비밀번호**: 회전하는 코드를 생성하는 Google Authenticator 같은 인증 앱.
- **이메일**: 이메일로 전송되는 일회용 코드.
- **휴대전화(SMS)**: 문자 메시지로 전송되는 일회용 코드. Enterprise 플랜에서 사용할 수 있습니다.
- **복구 코드**: 주 방법을 사용할 수 없을 때를 위한 일회용 백업 코드.

**MFA 설정**: 프로필 보안 설정에서 인증 방법을 추가하고, 복구 코드를 안전한 곳에 보관하세요. 복구 코드는 비밀번호처럼 다뤄야 합니다. 이를 가진 사람은 누구나 MFA를 우회할 수 있습니다.

#### MFA 시행

워크스페이스 관리자는 **Policies > Authentication**(Superuser 전용, Alpacon Cloud/Auth0 워크스페이스)에서 MFA를 구성합니다:

- **추가 인증 필수**: 활성화하면 워크스페이스 로그인 시 다중 인증이 요구됩니다.
- **허용된 추가 인증 수단**: 위 방법 중 사용자가 등록할 수 있는 것을 선택합니다. 이 목록이 패스키 로그인을 MFA로 인정할지도 결정합니다. [패스키와 허용된 MFA 수단](/use/workspace/settings/#패스키와-허용된-mfa-수단)을 참고하세요.
- **추가 인증 유지 시간**: MFA 인증은 기본 1시간 동안 유효합니다. Enterprise 플랜에서는 관리자가 1분에서 1일까지 변경할 수 있지만, 민감 작업 추가 인증 유지 시간보다 짧게 설정할 수 없습니다.
- **민감 작업 추가 인증 유지 시간**: 민감 작업의 MFA 인증은 기본 15분 동안 유효합니다. 추가 인증 유지 시간보다 길게 설정할 수 없으며, Enterprise 플랜에서는 관리자가 변경할 수 있습니다.
- **MFA 인증 대상**: 특정 권한 작업(예: 시스템 계정으로 Websh 접속, 에이전트 업그레이드) 전에 새로운 MFA 인증을 요구합니다. Enterprise 플랜에서 사용할 수 있으며 기본적으로 선택된 작업은 없습니다.

워크스페이스의 플랜이 Enterprise에서 바뀌면 **추가 인증 유지 시간**은 1시간, **민감 작업 추가 인증 유지 시간**은 15분으로 돌아가고 **MFA 인증 대상**에서 선택한 작업은 모두 해제됩니다. 값이 바뀐 항목이 있으면 변경 전후 값이 활동 기록에 남습니다.

### 추가 인증 (step-up authentication)

Alpacon은 로그인한 상태에서도 **새로운 MFA 인증**을 요구할 수 있습니다. 모든 플랜에서 sudo 사용, 보안 설정 변경, MFA 수단 등록, sudo·승인 정책 수정, 역할과 역할 바인딩 변경, 상시 권한을 부여하는 요청의 결정에는 **민감 작업 추가 인증 유지 시간**이 적용됩니다. 이 인증은 Enterprise 플랜의 MFA 필수 작업 목록과 별개로 적용됩니다. Enterprise 플랜에서는 관리자가 아래 작업도 선택할 수 있습니다.

#### 추가 인증을 요구할 수 있는 작업

Enterprise 플랜에서 워크스페이스 관리자는 **MFA 인증 대상**에서 새로운 MFA 인증을 요구할 작업을 선택합니다. 기본적으로 선택된 작업은 없습니다.

- **서버 작업**: 에이전트 업그레이드·재시작, alpamon-pam 설치
- **웹 터미널**: 본인 계정이 아닌 시스템 계정으로 접속
- **코드 에디터**: 본인 계정이 아닌 시스템 계정으로 에디터 열기
- **파일 전송**: 본인 계정이 아닌 시스템 계정으로 파일 전송
- **명령 실행**: 본인 계정이 아닌 시스템 계정으로 실행
- **승인 처리**: 검토자로서 요청 승인 또는 반려

**Windows**에서는 해당되는 작업(Websh, WebFTP, 명령 실행)이 선택한 계정과 무관하게 SYSTEM 권한으로 실행되며, 계정은 감사 라벨입니다. [Windows 서버](/reference/platforms/windows/#windows의-권한과-사용자-식별)를 참고하세요.

권한 상승(sudo)은 [sudo with MFA](/use/work-sessions/terminal/sudo-with-mfa/) 승인 흐름으로 별도 처리됩니다. 이 흐름에는 Auth0가 필요하므로 Auth0가 없는 셀프 호스팅 배포에서는 MFA가 필요한 `sudo`를 즉시 거부합니다. 이 경우 권한을 높이려면 세션 승인이 sudo MFA를 대신하는 정책이 있는 작업 세션을 사용하세요([`alpacon work-session create --sudo`](/reference/cli/work-session/create/) 참고).

**작동 방식**:

1. **초기 로그인**: 비밀번호 + MFA로 인증
2. **권한 있는 작업**: 보호된 작업 시도
3. **추가 인증 프롬프트**: 추가 인증 유지 시간이 지났으면 MFA로 재인증
4. **시간 제한**: 인증은 추가 인증 유지 시간 동안 유효 (기본 1시간, 구성 가능)
5. **자동 만료**: 타임아웃 후 재인증 필요

**예시 흐름**:
```
사용자 로그인 → [비밀번호 + MFA] → 접근 허용 (표준 권한)
                      ↓
사용자가 "root로 prod-db-01 연결" 클릭
                      ↓
추가 인증 필요 → [MFA 확인]
                      ↓
MFA 인증 유효 (1시간)
```

**보안 이점**:
- **세션 하이재킹 방지**: 도용된 세션으로 권한 있는 리소스에 접근할 수 없음
- **피해 범위 제한**: 침해된 계정의 잠재적 피해가 제한됨
- **감사 추적**: 일반 접근과 권한 있는 접근의 명확한 구분
- **컴플라이언스**: 권한 있는 접근 관리(PAM) 요구사항 충족

**모범 사례**:
- Enterprise 플랜에서는 프로덕션 워크스페이스의 추가 인증 유지 시간을 줄이되, 민감 작업 추가 인증 유지 시간보다 짧게 설정하지 않음
- 권한 있는 접근에 하드웨어 키 또는 생체 인증 요구
- 모든 추가 인증에 대한 알림 활성화
- 권한 있는 접근 로그 정기적으로 검토

### 싱글 사인온(SSO)

Auth0를 통해 다음 SSO 방식을 사용할 수 있습니다.

- **Google Workspace**: 조직의 Google 계정으로 로그인합니다
- **Okta**: Enterprise 워크스페이스는 Okta Integration Network로 연동할 수 있습니다([SSO 통합](/integrate/sso/) 참고)
- **SAML IdP(Enterprise)**: 조직의 SAML IdP를 연동할 수 있습니다. 온보딩 과정에서 AlpacaX 팀이 함께 구성합니다

다른 IdP 연동이 필요한 조직은 [support@alpacax.com](mailto:support@alpacax.com)으로 문의해 주세요.

### API 토큰 및 서비스 토큰

프로그래밍 방식 접근과 자동화에 쓰는 토큰입니다.

#### API 토큰

- CLI 및 API 접근용 토큰: 왼쪽 사이드바 맨 아래의 계정 카드를 클릭하고 **내 API 토큰** → **추가**를 선택하면 **새 API 토큰**을 열 수 있음
- 리소스별 세분화된 `resource:action` 범위(예: `server:read`, `server:update`) 및 명령/서버 ACL 규칙
- 개인 토큰과 등록 토큰은 Policies > Server access의 **토큰 최대 사용 기간** 이내에 만료됨(1~366일, 기본값 366일). 서비스 토큰은 이 제한에서 제외
- 언제든지 취소 가능

**API 토큰 생성**:
```bash
# 웹 콘솔: 계정 카드 > 내 API 토큰 > 추가

# 토큰 사용
export ALPACON_TOKEN="your-token-here"
alpacon server list
```

#### 애플리케이션 및 서비스 토큰

**애플리케이션**은 자동화를 위한, 사람이 아닌 신원입니다. 각 애플리케이션은 자신의 역할과 권한을 그대로 물려받는 **서비스 토큰**을 발급합니다:

- 개별 사용자와 연결되지 않음
- 애플리케이션의 역할과 범위로 권한이 정의됨
- 토큰별로 활동 기록

**사용 사례**:
- CI/CD 파이프라인
- 모니터링 통합
- 자동화된 배포
- 서드파티 도구 통합

## 접근 제어

### 역할 기반 접근 제어(RBAC)

Alpacon은 역할 기반 권한 시스템을 사용하며, 여기에는 기본 제공 역할과 사용자 정의 역할이 있습니다.

#### 기본 제공 역할

기본 제공 역할은 사용자의 역할 설정에 따라 자동 할당됩니다:

**1. 멤버(일반 사용자)** → 워크스페이스 전체 역할 없음
- 워크스페이스 전체 범위의 기본 제공 역할이 부여되지 않으며, 접근 권한은 그룹 멤버십과 직접 할당된 역할에서 옵니다
- 할당된 서버 및 리소스에만 접근
- 워크스페이스 설정 수정 불가
- 다른 사용자 초대 불가

**2. 스태프** → RBAC 역할: `admin`
- 관리 권한
- 서버 및 사용자 관리 가능
- 사용자 그룹 구성 가능
- 감사 로그 조회 가능
- 워크스페이스 청구 수정 또는 워크스페이스 삭제 불가

**3. 슈퍼유저** → RBAC 역할: `superuser`
- 전체 관리 접근 권한
- 모든 워크스페이스 설정 수정 가능
- 청구 및 구독 관리 가능
- 워크스페이스 삭제 가능
- 다른 사용자 승격/강등 가능

사용자를 Staff로 설정하면 RBAC `admin` 역할이, Superuser로 설정하면 `superuser` 역할이 자동 할당됩니다.

#### 사용자 정의 역할

기본 제공 역할 외에도, Superuser는 세밀한 권한을 가진 사용자 정의 역할을 생성하고 관리할 수 있습니다:

- **권한 형식**: 각 권한은 `resource:action` 형식을 따릅니다(예: `server:read`, `server:update`). 전체 목록은 [접근 범위 레퍼런스](/reference/scopes/) 참고
- **전역 범위**: 해당 리소스 유형의 모든 오브젝트에 권한이 적용됩니다
- **오브젝트 범위**: 특정 리소스 유형과 오브젝트로 권한을 제한할 수 있습니다

사용자 정의 역할은 개별 사용자 또는 그룹에 할당할 수 있습니다. 그룹에 역할을 할당하면 그룹의 모든 멤버가 해당 역할의 권한을 상속받습니다.

역할 관리는 [워크스페이스 설정 > 역할](/use/workspace/settings/#역할)에서 할 수 있습니다.

#### 리소스 범위 역할

리소스 범위 역할도 기본 제공 역할처럼 Alpacon에 처음부터 들어 있지만, 워크스페이스 전체가 아니라 특정 서버나 그룹 같은 개별 리소스 하나에만 적용됩니다(예: `server:maintainer`, `group:member`). 각 역할이 어떻게 할당되는지는 역할 목록의 설명에서 확인할 수 있습니다.

#### 권한 매트릭스

| 작업 | 멤버 | 스태프 | 슈퍼유저 |
|--------|--------|-------|-----------|
| 할당된 서버 접근 | ✓ | ✓ | ✓ |
| 터미널 세션 생성 | ✓ | ✓ | ✓ |
| WebFTP 사용 | ✓ | ✓ | ✓ |
| 본인 활동 로그 조회 | ✓ | ✓ | ✓ |
| 서버 관리 | ✗ | ✓ | ✓ |
| 사용자 초대/제거 | ✗ | ✓ | ✓ |
| 사용자 그룹 관리 | ✗ | ✓ | ✓ |
| 모든 감사 로그 조회 | ✗ | ✓ | ✓ |
| 워크스페이스 설정 구성 | ✗ | △ | ✓ |
| 청구 관리 | ✗ | ✗ | ✓ |
| 워크스페이스 삭제 | ✗ | ✗ | ✓ |

> ✓ 전체 접근 · △ 제한된 접근(읽기 전용) · ✗ 접근 불가

### 사용자 그룹

사용자 그룹을 활용하면 권한을 효율적으로 관리할 수 있습니다:

**이점**:
- 여러 사용자에게 한 번에 권한 할당
- 팀, 부서 또는 역할별로 사용자 구성
- 동적 접근 제어(그룹에 사용자 추가 → 즉시 접근)
- 더 쉬운 감사 및 컴플라이언스

**역할 상속**: 그룹에 역할을 할당하면 그룹의 모든 멤버가 해당 역할의 권한을 상속받습니다. 사용자의 유효 권한은 직접 할당된 역할과 그룹에서 상속받은 역할의 합산입니다.

**모범 사례**:
- 개인이 아닌 직무 기능을 기반으로 그룹 생성
- 명명 규칙 사용(예: `team-devops`, `team-security`)
- 정기적인 그룹 멤버십 검토
- 그룹 목적 및 접근 수준 문서화

### 서버 수준 접근 제어

서버 접근을 세밀하게 제어할 수 있습니다.

#### 사용자 할당

- **직접 할당**: 특정 사용자를 서버에 할당
- **그룹 할당**: 서버에 그룹 할당(권장)
- **와일드카드 매칭**: 패턴을 사용하여 접근 할당(예: `web-*`, `*-prod`)

#### 작업 세션 범위

서버를 사용하려면, 필요한 작업으로 범위를 좁힌 시간 제한 작업 세션을 요청합니다:

- **웹 터미널**: 브라우저 터미널 접근(Websh)
- **파일 전송**: 파일 업로드 및 다운로드(WebFTP)
- **명령 실행**: 여러 서버에서 명령 실행
- **코드 에디터**: 브라우저에서 파일 편집
- **포트 포워딩**: 서버의 서비스로 터널링
- **권한 상승**: sudo, sudo with MFA 정책으로 제어됨

사용자가 요청할 수 있는 범위는 RBAC 역할과 그룹 멤버십에 따라 제한됩니다.

### 임시 접근

서버에 시간 제한 접근 권한을 부여합니다:

```yaml
# 임시 접근 구성
user: john@company.com
server: production-db-01
access_level: full
duration: 4h
reason: "Emergency database recovery"
approval_required: true
approver: alice@company.com
```

**기능**:
- 자동 만료(1시간에서 30일)
- 승인 워크플로(선택 사항)
- 사유가 포함된 감사 추적
- 만료 전 알림
- 만료 후 자동 취소

## 세션 관리

### 세션 보안

- **작업 세션 만료**: 접근은 자동으로 만료되는 시간 제한 작업 세션으로 부여됩니다
- **Websh 세션 타임아웃**: 브라우저 터미널은 구성 가능한 시간(10분에서 1일) 동안 세션을 유지합니다
- **원격 세션 종료**: 사용자 또는 관리자가 언제든지 활성 세션을 종료할 수 있습니다

### MFA 유효 기간

MFA를 완료하면 워크스페이스의 **추가 인증 유지 시간**(기본 1시간) 동안 인증이 유효하며, 그 후 다시 인증을 요구합니다. **MFA 인증 대상** 설정의 작업은 유효 시간이 지나면 새로운 인증을 요구합니다.

## 네트워크 보안 이점

Alpacon의 게이트웨이 기반 아키텍처는 기존 SSH 방식보다 네트워크 보안 면에서 큰 이점을 제공합니다:

### 개방 포트 제로

**인바운드 포트 불필요**:
- 서버는 SSH(포트 22) 또는 다른 포트를 인터넷에 절대 노출하지 않음
- Alpamon 에이전트가 Alpacon 게이트웨이로 아웃바운드 전용 연결 시작
- 모든 연결은 HTTPS를 통한 암호화된 WSS(WebSocket Secure)로 진행

**공격 표면 제거**:
- **네트워크 스캐닝 불가**: 공격자가 포트 스캐닝을 통해 서버를 발견할 수 없음
- **SSH 무차별 대입 공격 불가**: SSH 포트가 노출되지 않아 무차별 대입 공격 벡터 제거
- **직접 접근 불가**: 서버가 외부 공격자에게 보이지 않음

### 수평 이동(lateral movement) 방지

**격리된 서버 연결**:
- 각 서버가 게이트웨이에 독립적으로 연결
- 서버들이 Alpacon을 통해 서로 직접 통신할 수 없음
- 한 서버가 침해되어도 Alpacon 연결을 통해 다른 서버에 접근할 수 없음

**내부 공격 전파 방지**:
- 공격자가 하나의 서버에 접근하더라도 Alpacon을 사용하여 다른 서버로 피봇할 수 없음
- 게이트웨이가 모든 연결에 대해 인증 및 권한 부여 시행
- Alpacon을 통한 서버 간 신뢰 관계 없음

### 중앙 집중식 보안 시행

**보안 체크포인트로서의 게이트웨이**:
- 모든 트래픽이 Alpacon 게이트웨이를 통과하므로 접근이 중앙에서 인증 및 권한 부여됩니다
- 세션과 명령이 기록되고 위험도가 평가됩니다(세션 종료 후 AI 위험 분석 실행)
- 중앙 집중식 접근 제어로 서버별 보안 구성 불필요
- 모든 서버에 대한 즉각적인 접근 권한 취소

**심층 방어**:
- 다층 인증(비밀번호/SSO + MFA + 추가 인증)
- 네트워크 수준 격리(개방 포트 없음) + 애플리케이션 수준 보안(IAM, RBAC)
- 지속적인 모니터링 및 감사 로깅

### 기존 SSH와의 비교

| 보안 측면 | 기존 SSH | Alpacon 게이트웨이 |
|---------|---------|------------------|
| **포트 노출** | 포트 22를 인터넷에 노출 | 개방 포트 없음 |
| **네트워크 스캐닝** | 포트 스캐닝에 취약 | 스캐너에 보이지 않음 |
| **무차별 대입 공격** | SSH 무차별 대입 공격의 직접 타겟 | 공격할 SSH 포트 없음 |
| **수평 이동** | 도난당한 키로 가능 | 중앙 집중식 인증으로 방지 |
| **접근 권한 취소** | 모든 서버 업데이트 필요 | 모든 서버에 즉시 적용 |
| **감사 추적** | 서버별, 종종 불완전 | 중앙 집중식, 완전함 |
| **정책 시행** | 서버별 구성 | 중앙 집중식, 일관성 있음 |

## IP 허용 목록

출발지 IP 주소를 기준으로 접근을 제한해 보안을 한층 강화할 수 있습니다.

### 서비스 토큰 IP 허용 목록 (지금 사용 가능)

프로그래밍 방식 접근은 토큰 단위로 제한할 수 있습니다. 각 서비스 토큰은 다음을 지원합니다:

- **IP/CIDR 허용 목록**: 특정 IP 주소나 범위에서만 토큰 사용 허용
- **사용 시간대 제한**: 토큰을 사용할 수 있는 시간과 요일 지정
- **요청 속도 제한**: 토큰별 요청 속도 상한 설정

자세한 구성 방법은 [서비스 토큰](/use/iam/applications/service-tokens/)을 참고하세요.

### 워크스페이스 수준 IP 접근 정책 (Enterprise)

Enterprise 워크스페이스는 사무실 네트워크나 VPN 게이트웨이 같은 특정 IP 범위로 워크스페이스 접근을 제한할 수 있습니다. 도입이 필요하시면 [support@alpacax.com](mailto:support@alpacax.com)으로 문의해 주세요.

## 감사 로깅

인증과 접근 이벤트를 빠짐없이 기록합니다.

### 기록되는 이벤트

**인증**:
- 로그인 시도(성공 및 실패)
- 로그아웃 이벤트
- MFA 인증
- 비밀번호 변경
- SSO 인증

**권한 부여**:
- 권한 변경
- 역할 할당
- 그룹 멤버십 변경
- 접근 거부

**리소스 접근**:
- 서버 연결
- 터미널 세션 생성
- WebFTP 파일 작업
- API 호출

### 활동 기록 조회 범위

- Free: 활동 로그는 제공되지 않으며 최근 7일 동안 본인의 세션 및 명령 기록만 조회할 수 있습니다
- Essentials: 최근 120일의 활동 기록을 조회할 수 있습니다
- Enterprise: 최근 365일의 활동 기록을 조회할 수 있으며 계약에 따라 연장할 수 있습니다

이 기간은 조회 가능 범위이며, 기록이 삭제되는 시점을 뜻하지 않습니다.

### 감사 활동 검토

CLI에서 `alpacon audit`으로 감사 활동을 검토합니다:

```bash
# 최근 감사 활동
alpacon audit --tail 50

# 사용자로 필터링
alpacon audit --user john@company.com

# 애플리케이션 및 모델로 필터링
alpacon audit --app cert --model authority
```

## 데이터 프라이버시 및 워크스페이스 격리

Alpacon은 프라이버시와 데이터 격리를 핵심 원칙으로 삼아 설계되었습니다.

### 완전한 워크스페이스 격리

각 워크스페이스는 완전히 격리된 환경에서 작동합니다:

- **데이터 분리**: 워크스페이스 데이터는 데이터베이스 및 애플리케이션 수준에서 완전히 분리됨
- **워크스페이스 간 접근 불가**: 한 워크스페이스의 사용자는 다른 워크스페이스의 데이터에 접근하거나 볼 수 없음
- **격리된 인증**: 사용자 계정 및 권한은 워크스페이스별로 관리됨
- **네트워크 격리**: 각 워크스페이스는 격리된 네트워크 정책 및 접근 제어를 가짐

### 내부 접근 제어

**워크스페이스 데이터는 엄격한 내부 접근 제어로 보호됩니다:**

- **승인 기반 접근**: AlpacaX 담당자의 프로덕션 접근은 승인을 거쳐야 하고, 시간 제한이 있으며, 모두 감사 기록으로 남습니다
- **키 관리**: 암호화 키는 리전마다 전용 키 관리 시스템에서 관리합니다
- **저장 시 암호화**: 워크스페이스 데이터는 저장 시 암호화됩니다
- **감사 추적 프라이버시**: 제품 내 워크스페이스 감사 로그는 워크스페이스 관리자만 볼 수 있습니다
- **서버 자격 증명**: 서버 연결 자격 증명은 암호화되어 저장됩니다

일상적인 플랫폼 운영은 인프라 상태 데이터, 시스템 수준 로그, 집계된 사용 지표, 청구 정보를 기반으로 하며, 워크스페이스 내부 데이터에 의존하지 않습니다.

### 워크스페이스 삭제

Superuser만 워크스페이스를 삭제할 수 있습니다. 삭제를 확인하면 유예 기간 없이 진행되며 되돌릴 수 없습니다. 워크스페이스의 데이터베이스 행은 즉시 삭제됩니다. 활동 기록, 세션 녹화 및 로그는 곧이어 보통 몇 분 안에 삭제됩니다. 백업은 3일 이내에 만료됩니다. 개인 정보가 포함되지 않은 무결성 해시는 보관됩니다.

### 데이터 소유권

- **데이터 소유권은 고객에게**: 워크스페이스의 모든 데이터는 고객의 것입니다
- **데이터 내보내기**: 마이그레이션이나 컴플라이언스 목적으로 데이터가 필요하시면 [support@alpacax.com](mailto:support@alpacax.com)으로 요청해 주세요

## 모범 사례

### 관리자용

1. **MFA 시행**: 모든 사용자, 특히 관리자에게 MFA 요구
2. **그룹 사용**: 개별 사용자가 아닌 그룹을 통해 권한 관리
3. **최소 권한**: 필요한 최소 권한만 부여
4. **정기 검토**: 분기별 사용자 접근 감사
5. **로그 모니터링**: 의심스러운 활동에 대한 알림 설정
6. **SSO 통합**: 중앙 집중식 사용자 관리를 위해 SSO 사용(엔터프라이즈)
7. **하드웨어 MFA**: 높은 보안 환경에서는 하드웨어 키 또는 생체 인증으로 제한 고려

### 사용자용

1. **강력한 비밀번호**: 비밀번호 관리자 사용 및 고유한 비밀번호
2. **MFA 활성화**: 다중 인증으로 계정 보호
3. **세션 검토**: 정기적으로 이전 세션 확인 및 종료
4. **의심스러운 활동 보고**: 비정상적인 로그인 알림 즉시 보고
5. **토큰 보안**: API 토큰을 절대 공유하거나 코드에 커밋하지 말 것

## 관련 문서

- [보안 개요](/learn/security/) - 전반적인 보안 접근 방식
- [IAM 관리](/use/iam/) - 상세한 IAM 구성 가이드
- [사용자 그룹](/use/iam/groups/) - 사용자 그룹 관리
- [감사 로그](/use/audit/) - 감사 로그 보기 및 분석

## 문의

인증 및 접근 제어 문의:

- 이메일: [security@alpacax.com](mailto:security@alpacax.com)
- 지원: [support@alpacax.com](mailto:support@alpacax.com)

---

*최종 업데이트: 2025년 11월*

Source: https://docs.alpacax.com/ko/learn/security/authentication/