공격 반경 줄이기 | Teleport 공식 기술 문서 한국판 by 인포그랩

공격 반경 줄이기

Teleport는 사용자가 공격에 대한 인프라의 모든 구성 요소가 안전하도록 방어 심층을 실천할 것을 권장합니다. 공격자가 부분적으로 성공하더라도 안전해야 합니다. 사용자가 인증하거나 권한을 요청할 때 Teleport를 구성하여 클러스터에 보호 계층을 추가할 수 있습니다. 이 가이드에서는 다음과 같은 방법을 보여드립니다:

MFA를 tsh 로그인에 필수로 설정하기
리소스에 접근할 때마다 MFA 도전 문제 제기하기
역할 요청에 이중 승인을 요구하기
일부 역할이 다른 역할을 요청하지 못하도록 자동으로 방지하기
사용자 특성에 따라 역할 요청 제한하기
관리자 역할 없이 RBAC 설정하기
당신의 Teleport 클러스터에 연결할 수 있는지 확인하려면, tsh login으로 로그인한 다음 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:
```
tsh login --proxy=teleport.example.com --user=email@example.com
tctl status
클러스터  teleport.example.com
버전  16.2.0
CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
```
클러스터에 연결하고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 작업대에서 후속 tctl 명령어를 실행할 수 있습니다. 자신의 Teleport 클러스터를 호스팅하는 경우, Teleport 인증 서비스를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.

MFA를 `tsh login`에 필수로 설정하기

사용자가 비밀번호만으로 Teleport 클러스터에 인증하기 위해 계정을 설정하면, 공격자가 무차별 대입 공격, 중간자 공격 또는 피싱을 통해 비밀번호에 접근할 수 있습니다. 그러나 사용자의 비밀번호가 손상되더라도 공격자가 tsh login을 실행할 때 이를 인증하지 못하도록 할 수 있습니다.

Teleport는 사용자가 계정을 생성할 때 MFA 장치를 등록해야 하며, 새 Teleport 세션을 시작할 때 해당 장치를 사용하여 인증하도록 요구할 수 있습니다.

이를 위해 환경에 따라 다음과 같은 변경을 수행하십시오:

auth_service.authentication.second_factor의 값이 otp, webauthn 또는 on인지 확인하십시오:

auth_service:
  authentication:
    second_factor: webauthn

기존의 cluster_auth_preference 리소스를 가져옵니다:

tctl get cap > cap.yaml

cap.yaml에서, spec.second_factor의 값이 otp, webauthn 또는 on인지 확인합니다:

kind: cluster_auth_preference
version: v2
metadata:
  name: cluster-auth-preference
spec:
  second_factor: "otp"

변경 사항을 적용하십시오:

tctl create -f cap.yaml

모든 사용자에 대해 MFA를 필수로 하려면, second_factor는 다음 값 중 하나로 설정해야 합니다:

otp
webauthn
on

모든 사용자가 MFA를 요구하면서 OTP 또는 WebAuthn 장치를 선택할 수 있도록 하려면 on을 선택하십시오. 다른 옵션은 사용자가 특정 MFA 장치 유형으로 제한되어 있어, 특정 보안 표준을 강제하는 데 유용합니다. second_factor 구성 옵션이 이러한 값 중 하나로 설정되면, Teleport는 MFA를 다음과 같이 강제합니다:

사용자가 선택한 종류의 MFA 장치를 등록해야 하도록 Teleport 회원가입 페이지를 조정합니다. second_factor의 값이 on이면 사용자는 여러 장치 유형 중에서 선택할 수 있습니다.
사용자가 tsh login을 실행할 때 MFA 도전 과제를 제시합니다.

귀하의 Teleport 환경에서 SSO를 활성화한 경우, 로그인 시 MFA 도전 과제는 로컬 사용자에게만 적용되지만 IdP는 자체 MFA 검사를 적용할 수 있습니다.

Warning

second_factor 구성이 off로 설정되어 있고 사용자가 두 번째 요소 없이 계정을 생성한 경우, MFA를 요구하는 값으로 second_factor를 변경하면 해당 사용자는 등록하지 않은 자격 증명으로 인증해야 하므로 계정에서 잠길 수 있습니다. 이 시나리오를 피하는 두 가지 방법이 있습니다:

기존 사용자가 MFA 장치를 등록했는지 확인할 때까지 second_factor를 optional로 설정합니다.
사용자가 새로운 자격 증명을 입력하도록 강제하려면 tctl users reset <account> 명령을 실행합니다. 여기에는 필요한 MFA 장치도 포함됩니다.

리소스에 접근할 때마다 MFA 도전 문제 제기하기

사용자가 Teleport 클러스터에 로그인한 후, 특정 리소스(예: 노드, 데이터베이스, 애플리케이션 또는 Kubernetes 클러스터)에 대한 접근을 요청할 수 있습니다. 이 경우, Teleport Auth Service는 해당 리소스에 접근하기 위한 단기 인증서를 발급합니다. 손상된 인증서를 가진 공격자가 피해를 주지 못하도록 세션마다 MFA를 활성화할 수 있습니다. 이 설정을 사용하면 사용자가 리소스에 접근하기 위해 일회성 인증서를 요청할 때마다 Teleport Auth Service가 MFA 도전 과제를 제공합니다. 이미 tsh login을 통해 Teleport 세션을 시작한 경우에도 그렇습니다.

모든 사용자를 위해 세션마다 MFA를 활성화하려면 Teleport 환경에 따라 다음을 수행하십시오:

Teleport 구성 파일을 다음과 같이 변경합니다:

auth_service:
  authentication:
    require_session_mfa: yes

다음 cluster_auth_preference 동적 리소스를 생성합니다:

kind: cluster_auth_preference
version: v2
metadata:
  name: cluster-auth-preference
spec:
  require_session_mfa: yes

YAML 파일의 경로를 사용하여 동적 리소스를 생성합니다: tctl create -f <path to your YAML file> .

SSO 사용자는 세션마다 MFA를 사용하기 위해 Teleport에 MFA 장치를 추가해야 합니다.

역할 요청에 이중 승인을 요구하기

공격자가 사용자 자격 증명에 접근하고 Teleport 클러스터에 성공적으로 로그인하더라도 해당 사용자가 권한을 상승시키지 못하도록 방지할 수 있습니다. 이중 승인을 활성화하면, 특정 역할을 맡으려는 사용자는 두 명 이상의 검토자로부터 승인을 받아야 합니다. 이렇게 하면 악의적인 사용자가 정당한 사용자를 가장해도, 검토자는 새 역할을 부여하기 전에 실제 사용자에게 연락할 수 있습니다.

이중 승인은 Teleport의 액세스 플러그인(예: Slack, JIRA, PagerDuty)을 사용하여 사용자가 역할을 요청했음을 검토자에게 알립니다. SAML 또는 OIDC 커넥터가 필요한 액세스 플러그인의 경우, Teleport의 클라우드 또는 엔터프라이즈 버전을 활성화해야 합니다.

이중 승인을 설정하려면 두 개의 동적 리소스를 적용해야 합니다:

검토자
리뷰이

검토자

일부 사용자가 다른 사용자의 역할 상승 요청을 검토할 수 있도록 다음과 유사한 동적 리소스를 적용하여 활성화할 수 있습니다:

kind: role
version: v5
metadata:
  name: reviewer
spec:
  allow:
    review_requests:
      roles: ["role-one", "role-two", "role-three"]

spec.allow.review_requests.roles를 역할 이름 목록에 할당합니다. 사용자가 spec.allow.review_requests.roles에 나열된 역할에 대한 접근을 요청하면, Teleport 액세스 플러그인은 reviewer 역할을 가진 사용자에게 요청을 알리고 응답을 Teleport 클러스터로 전달합니다.

리뷰이

리뷰자로부터 접근을 요청해야 하는 사용자를 요구하기 위해 다음과 유사한 동적 리소스를 적용할 수 있습니다:

kind: role
version: v5
metadata:
  name: reviewee
spec:
  allow:
    request:
      roles: ["role-one", "role-two", "role-three"]
      thresholds:
        - approve: 2
          deny: 1

spec.allow.request.roles 필드는 '리뷰이' 역할을 가진 사용자가 요청할 수 있는 다른 역할의 이름 목록을 나열합니다. 리뷰이가 이러한 역할에 접근을 요청하면 Teleport는 액세스 플러그인을 통해 검토자에게 알립니다. spec.allow.requests.roles.thresholds 필드는 요청을 승인하거나 거부하는 데 필요한 검토 수를 나타냅니다.

일부 역할이 다른 역할을 요청하지 못하도록 자동으로 방지하기

악의적인 Teleport 사용자가 더 권한이 있는 역할을 요청하고, 검토자를 속여 접근을 부여받을 수 있습니다. 특정 역할에 대한 접근 요청을 아예 하지 못하도록 역할을 정의하여 이러한 시나리오를 방지할 수 있습니다.

spec.deny 필드는 이전에서 설명한 spec.allow 필드와 동일한 속성을 가질 수 있지만, 액세스를 활성화하는 대신 비활성화합니다. 예를 들어, spec.deny.requests.roles 필드는 사용자가 요청할 수 없는 역할 목록입니다. Teleport는 액세스 요청을 실행할 때 deny 규칙에 우선순위를 부여합니다.

예를 들어, 사용자 myuser가 다음 템플릿을 사용하여 정의된 user 역할에 할당되었습니다:

kind: role
version: v5
metadata:
  name: user
spec:
  deny:
    request:
      roles: ['admin']

그런 다음, myuser가 admin 역할을 요청하려고 합니다.

tsh request create --roles=admin

그러나 Auth Service는 요청을 거부합니다.

Creating request...ERROR: user "myuser" can not request role "admin"

사용자 특성에 따라 역할 요청 제한하기

Teleport의 role 리소스를 사용하여 특정 속성을 가진 사용자가 특정 역할에 대한 접근을 제한하여 우연한 권한 상승을 방지할 수 있습니다. 사용자에게 traits 목록을 할당한 후, 특정 속성이 정규 표현식과 일치하는 사용자가 권한 상승 요청을 하지 않도록 방지하는 role 리소스를 정의합니다.

사용자는 획득한 역할에 관계없이 동일한 특성을 가집니다. 결과적으로 사용자가 RBAC 오류로 인해 다른 역할을 획득하게 되더라도, 특성 기반 제한을 사용하여 더 높은 권한의 역할 요청을 중단할 수 있습니다.

가령, 재무 데이터를 분석하기 위해 고용한 계약자를 위한 다음 역할을 정의했다고 가정합시다.

kind: user
version: v2
metadata:
  name: myuser
spec:
  roles:
    - analyst # 비특권 역할
  traits:
    logins:
      - myuser
    groups:
      - contractors

분석가는 종종 조직의 데이터베이스에 대한 쓰기 접근이 필요하여 db-writer 역할에 대한 접근을 요청할 수 있습니다. 신뢰하는 분석가만 이 접근을 요청할 수 있으며, 특별한 admins 그룹에 속합니다. deny 규칙을 사용하여, admins 그룹에 없는 분석가가 db-writer 역할에 대한 접근 요청을 하지 못하도록 할 수 있습니다:

kind: role
version: v5
metadata:
  name: analyst
spec:
  deny:
    request:
      claims_to_roles:
        - claim: groups
          value: "{{regexp.not_match(\"admin\")}}"
          roles: ["db-writer"]
  allow:
    request:
      roles: ["db-writer"]
      thresholds:
        - approve: 2
          deny: 1

claims_to_roles 필드는 사용자의 traits를 사용자가 요청할 수 있는 roles에 매핑합니다. 이 경우, {{regexp.not_match(\"admin\")}} 템플릿 함수로 사용자가 groups 특성에 administrator 또는 admins와 같은 값을 가지고 있는지 여부에 따라 db-writer 역할 요청을 방지합니다. 이러한 특성이 있는 사용자는 승인 두 요구 사항을 충족하여 해당 역할 요청이 가능합니다.

관리자 역할 없이 RBAC 설정하기

강력한 관리자나 심지어 고급 권한이 있는 reviewer 역할 없이 Teleport RBAC를 설계할 수 있습니다. 이렇게 하면 공격자가 Teleport 사용자로 위장하여 더 높은 권한의 역할을 요청할 경우, 공격 반경을 줄일 수 있습니다.

먼저, 특권이 있지만 제한된 접근이 있는 역할을 정의합니다. 다음 예제에서 editor 역할은 사용자 생성 시 정의된 로그인 외에도 인프라 내 호스트에서 editor로 로그인할 수 있습니다. 남용을 방지하기 위해 사용자가 발급받는 인증서는 근무일의 반나절만 유효합니다.

kind: role
version: v5
metadata:
  name: editor
spec:
  options:
    max_session_ttl: 4h
  allow:
    logins: [editor, "{{internal.logins}}"]

그런 다음 일반 user 역할을 정의합니다. 이 역할을 가진 사용자는 다른 사용자의 editor가 되기 위한 요청을 검토할 수 있으며, 두 번의 승인을 통해 editor 역할을 요청할 수 있습니다. 그러나 이 사용자는 인프라 내에서 editor로 로그인할 수 없습니다.

kind: role
version: v5
metadata:
  name: user
spec:
  allow:
    logins: ["{{internal.logins}}"]
    review_requests:
      roles: ['editor']
    request:
      roles: ["editor"]
      thresholds:
        - approve: 2
          deny: 1
  deny:
    logins: ["editor"]

두 명의 user가 별도의 reviewer 역할 없이 다른 user에게 일시적으로 고급 권한을 부여할 수 있습니다.

다음 단계

가이드

배경 읽기

인증 커넥터
프록시 서비스
인증 서비스
이 가이드에 설명된 역할은 internal 특성을 사용하며, Teleport는 이를 Teleport 로컬 사용자 데이터베이스의 값으로 교체합니다. Teleport 역할의 변수 확장 작동 방식에 대한 전체 세부정보는 Teleport 액세스 제어 참조를 참조하십시오.

Teleport 원문 보기

MFA를 tsh login에 필수로 설정하기