세션 및 신원 잠금 | Teleport 공식 기술 문서 한국판 by 인포그랩

세션 및 신원 잠금

시스템 관리자는 침해된 사용자 또는 Teleport 에이전트를 비활성화하거나 클러스터 유지 관리 중에 액세스를 방지하기 위해 세션, 사용자 또는 호스트 신원에 잠금을 설정할 수 있습니다.

Teleport는 새로운 API 요청을 거부하고 잠금의 대상에 해당하는 SSH, 애플리케이션, 데이터베이스, 데스크탑 및 Kubernetes 세션에 대한 활성 연결을 종료합니다.

잠금은 다음 객체 또는 속성을 대상으로 할 수 있습니다:

사용자의 이름으로 Teleport 사용자
역할의 이름으로 Teleport RBAC 역할
장치 ID로 Teleport 신뢰할 수 있는 장치
장치 UUID로 MFA 장치
OS/UNIX 로그인
에이전트의 서버 UUID로 Teleport 에이전트 (클러스터 등록 해제)
데스크탑의 이름으로 Windows 데스크탑
UUID로 액세스 요청

전제 조건

실행 중인 Teleport 클러스터 버전 17.0.0-dev 이상. Teleport를 시작하려면 가입하여 무료 평가판을 이용하거나 데모 환경 설정 방법을 확인하십시오.
tctl 관리자 도구와 tsh 클라이언트 도구.

tctl 및 tsh 다운로드 방법에 대한 지침은 설치를 방문하십시오.

연결이 가능한지 확인하기 위해 tsh login 으로 로그인한 다음, 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:
```
tsh login --proxy=teleport.example.com --user=email@example.com
tctl status
클러스터  teleport.example.com
버전  17.0.0-dev
CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
```
클러스터에 연결할 수 있고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 후속 tctl 명령어를 실행할 수 있습니다.
자신의 Teleport 클러스터를 호스팅하는 경우, Teleport Auth Service를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.

1/2단계. 잠금 생성

tctl lock 명령으로 새 잠금을 생성할 수 있습니다. 다음 옵션 중 하나로 잠금 대상을 지정하십시오:

tctl lock --user=foo@example.com --message="의심스러운 활동." --ttl=10h
이름 "dc7cee9d-fe5e-4534-a90d-db770f0234a1"의 잠금이 생성되었습니다.

대상 역할과 일치하는 역할이 할당된 모든 사용자가 잠금됩니다.

tctl lock --role=contractor --message="모든 계약자 접근이 10시간 동안 비활성화됩니다." --ttl=10h
이름 "dc7cee9d-fe5e-4534-a90d-db770f0234a1"의 잠금이 생성되었습니다.

장치 ID와 일치하는 장치에서 시작된 모든 연결이 잠금됩니다.

tctl lock --device 9cdfc0ad-64b7-4d9c-9342-50e97f418ba0 --message="침해된 장치" --ttl=48h
이름 "5444970a-39a0-4814-968d-e58b4a8fa686"의 잠금이 생성되었습니다.

장치 ID와 일치하는 per-session MFA로 시작된 모든 연결이 잠금됩니다.

tctl lock --mfa-device=d6c06a18-e147-4232-9dfe-6f83a28d5850 --message="모든 계약자 접근이 10시간 동안 비활성화됩니다." --ttl=10h
이름 "d6c06a18-e147-4232-9dfe-6f83a28d5850"의 잠금이 생성되었습니다.

지정된 에이전트에 대한 모든 연결이 잠금되고 에이전트가 Teleport 클러스터에서 제외됩니다.

tctl lock --server-id=363256df-f78a-4d99-803c-bae19da9ede4 --message="Kubernetes 서비스와 데이터베이스 서비스가 조사 중입니다." --ttl=10h
이름 "dc7cee9d-fe5e-4534-a90d-db770f0234a1"의 잠금이 생성되었습니다.

지정된 Windows 데스크탑에 대한 모든 연결이 잠금됩니다.

tctl lock --windows-desktop=WIN-FMPFM5UF1SS-teleport-example-com --ttl=10h
이름 "dc7cee9d-fe5e-4534-a90d-db770f0234a1"의 잠금이 생성되었습니다.

일치하는 액세스 요청에서 높은 권한을 사용하는 모든 연결이 잠금됩니다.

tctl lock --access-request=261e80c5-357b-4c43-9b67-40a6bc4c6e4d --ttl=24h
이름 "dc7cee9d-fe5e-4534-a90d-db770f0234a1"의 잠금이 생성되었습니다.

사용자에게 잠금 권한이 없으면 잠금을 생성할 때 오류가 발생합니다:

ERROR: access denied to perform action "create" on "lock"

locksmith 라는 역할을 정의합니다:

kind: role
version: v5
metadata:
  name: locksmith
spec:
  allow:
    rules:
      - resources: [lock]
        verbs: [list, create, read, update, delete]

역할을 생성합니다:

tctl create -f locksmith.yaml
역할 'locksmith'가 생성되었습니다.

locksmith 역할을 Teleport 사용자에게 할당하려면, 인증 제공자에 맞는 적절한 명령어를 실행하십시오:

로컬 사용자의 역할을 쉼표로 구분된 목록으로 가져옵니다:
```
ROLES=$(tsh status -f json | jq -r '.active.roles | join(",")')
```

새로운 역할을 추가하기 위해 로컬 사용자를 수정합니다:

tctl users update $(tsh status -f json | jq -r '.active.username') \  --set-roles "${ROLES?},locksmith"

Teleport 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

텍스트 편집기에서 github 인증 커넥터를 엽니다:
```
tctl edit github/github
```
github 커넥터를 수정하여 teams_to_roles 섹션에 locksmith 을 추가합니다.

이 역할에 매핑해야 하는 팀은 조직의 역할 기반 액세스 제어(RBAC) 설계에 따라 다릅니다. 그러나 팀은 귀하의 사용자 계정을 포함해야 하며, 조직 내에서 가장 작은 팀이어야 합니다.

예시는 다음과 같습니다:
```
  teams_to_roles:
    - organization: octocats
      team: admins
      roles:
        - access
+       - locksmith
```
파일을 편집하고 저장하여 변경 사항을 적용합니다.
Teleport 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

saml 구성 리소스를 가져옵니다:
```
tctl get --with-secrets saml/mysaml > saml.yaml
```
--with-secrets 플래그는 spec.signing_key_pair.private_key 의 값을 saml.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하므로, 리소스를 업데이트한 후 즉시 saml.yaml 파일을 삭제해야 합니다.
saml.yaml 을 수정하여 attributes_to_roles 섹션에 locksmith 을 추가합니다.

이 역할에 매핑해야 하는 속성은 조직의 역할 기반 액세스 제어(RBAC) 설계에 따라 다릅니다. 그러나 그룹은 귀하의 사용자 계정을 포함해야 하며, 조직 내에서 가장 작은 그룹이어야 합니다.

예시는 다음과 같습니다:
```
  attributes_to_roles:
    - name: "groups"
      value: "my-group"
      roles:
        - access
+       - locksmith
```
변경 사항을 적용합니다:
```
tctl create -f saml.yaml
```
Teleport 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

oidc 구성 리소스를 가져옵니다:
```
tctl get oidc/myoidc --with-secrets > oidc.yaml
```
--with-secrets 플래그는 spec.signing_key_pair.private_key 의 값을 oidc.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하므로, 리소스를 업데이트한 후 즉시 oidc.yaml 파일을 삭제해야 합니다.
oidc.yaml 을 수정하여 claims_to_roles 섹션에 locksmith 을 추가합니다.

이 역할에 매핑해야 하는 클레임은 조직의 역할 기반 액세스 제어(RBAC) 설계에 따라 다릅니다. 그러나 그룹은 귀하의 사용자 계정을 포함해야 하며, 조직 내에서 가장 작은 그룹이어야 합니다.

예시는 다음과 같습니다:
```
  claims_to_roles:
    - name: "groups"
      value: "my-group"
      roles:
        - access
+       - locksmith
```
변경 사항을 적용합니다:
```
tctl create -f oidc.yaml
```
Teleport 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

잠금이 적용되면 잠금의 대상과 관련된 모든 기존 연결이 종료되고 새로운 요청이 거부됩니다.

이 상황에서 반환되는 오류 및 경고는 다음과 같은 형식의 메시지를 특징으로 합니다:

User:"foo@example.com"에 대한 잠금이 적용 중입니다: 의심스러운 활동.

Note

--message 매개변수로 사용자에게 반환되는 메시지를 조정할 수 있습니다:

tctl lock --user=foo@example.com --message="내일 다시 오세요." --ttl=24h

--ttl 또는 --expires 를 지정하지 않으면 생성된 잠금은 tctl rm 을 사용하여 명시적으로 제거될 때까지 유효합니다. 지원되는 모든 매개변수 목록은 tctl lock --help 를 참조하십시오.

내부적으로, tctl lock 은 다음과 같은 리소스를 생성합니다:

kind: lock
version: v2
metadata:
  name: dc7cee9d-fe5e-4534-a90d-db770f0234a1
spec:
  target:
    user: foo@example.com
  message: "의심스러운 활동."
  expires: "2021-08-14T22:27:00Z" # RFC3339 형식

kind: lock 리소스는 일반적으로 tctl create 를 사용하여 생성 및 업데이트할 수 있습니다. 자세한 내용은 관리자 가이드를 참조하십시오.

2/2단계. 활성 잠금 목록 및 삭제

모든 활성 잠금을 나열하려면 tctl get 명령을 사용하세요:

tctl get locks

잠금 리소스를 삭제하려면:

tctl rm locks/24679348-baff-4987-a2cd-e820ab7f9d2b
lock "24679348-baff-4987-a2cd-e820ab7f9d2b" 가 삭제되었습니다

잠금을 삭제하면 새로운 세션이나 호스트 연결이 가능해집니다.

다음 단계: 잠금 모드

만약 Teleport 노드 또는 프록시 서비스가 로컬 잠금 뷰를 백엔드와 올바르게 동기화할 수 없다면, 마지막으로 알려진 잠금에 의존할지를 결정해야 합니다. 이 결정 전략은 두 가지 모드 중 하나로 인코딩됩니다:

strict 모드는 잠금이 최신 상태로 보장되지 않을 때 모든 상호작용을 종료합니다.
best_effort 모드는 최신 잠금에 계속 의존합니다.

클러스터 전체 모드는 기본적으로 best_effort 로 설정되어 있습니다. cluster_auth_preference 리소스 또는 정적 구성 파일을 사용하여 API 또는 CLI를 통해 기본 잠금 모드를 설정할 수 있습니다.

Auth 서비스 구성(/etc/teleport.yaml 기본값)에 auth_service.authentication 섹션이 포함되어 있다면, Teleport 구성 파일을 다음과 같이 수정하세요:

auth_service:
  authentication:
    locking_mode: best_effort

변경 사항을 적용하려면 Auth 서비스를 재시작하거나 재배포하세요.

포함되지 않은 경우, 클러스터 인증 기본 설정 리소스를 수정하세요:

tctl edit cap

편집기에 파일을 조정하여 다음을 포함하세요:

kind: cluster_auth_preference
metadata:
  name: cluster-auth-preference
spec:
  locking_mode: best_effort
version: v2

변경 사항을 적용하기 위해 편집기를 저장하고 닫으세요.

클러스터 전체 모드는 기본적으로 best_effort 로 설정되어 있습니다. API 또는 CLI를 사용하여 cluster_auth_preference 리소스를 통해 기본 잠금 모드를 설정할 수 있습니다:

tctl edit cap

편집기에 파일을 조정하여 다음을 포함하세요:

kind: cluster_auth_preference
metadata:
  name: cluster-auth-preference
spec:
  locking_mode: best_effort
version: v2

변경 사항을 적용하기 위해 편집기를 저장하고 닫으세요.

특정 역할에 대한 잠금 모드를 구성하는 것도 가능합니다:

kind: role
version: v5
metadata:
  name: example-role-with-strict-locking
spec:
  options:
    lock: strict

상호작용에 관련된 역할이 모드를 지정하지 않거나 사용자가 없는 경우, 모드는 클러스터 전체 설정에서 가져옵니다.

여러 잠금 모드(클러스터 전체 기본값 및 역할별 설정)가 충돌할 수 있을 때, strict 가 한 번만 발생해도 로컬 잠금 뷰는 엄격하게 평가됩니다.

Teleport 원문 보기