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

공격의 폭발 반경 줄이기

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

MFA를 tsh 로그인에 필수로 만들기
리소스에 접근 시 모든 시도에 MFA 챌린지 제공
역할 요청에 대해 이중 승인 요구
일부 역할이 다른 역할을 요청하지 못하도록 자동 방지
사용자 특성에 따라 역할 요청 제한
관리자 역할 없이 RBAC 설정하기
연결이 가능한지 확인하기 위해 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 명령어를 실행할 수도 있습니다.

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 edit cap

리소스에서 spec.second_factor 의 값이 otp , webauthn , 또는 on 인지 확인하십시오:

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

편집기에서 파일을 저장하고 닫아서 변경 사항을 적용하십시오.

모든 사용자에게 MFA를 필수로 만들기 위해서는 second_factor 를 다음 값 중 하나로 설정해야 합니다:

otp
webauthn
on

모든 사용자에게 MFA를 요구하려면 on 을 선택하되, OTP 또는 WebAuthn 장치를 선택하도록 허용합니다. 다른 옵션은 사용자가 특정 유형의 MFA 장치에 국한되도록 하여 특정 보안 표준을 강제하는 데 유용합니다. second_factor 구성 옵션을 이 값 중 하나로 설정하여 Teleport Proxy 서비스를 시작하면, Teleport는 다음과 같이 MFA를 강제합니다:

사용자가 선택한 종류의 MFA 장치를 등록해야 하도록 Teleport 가입 페이지를 조정합니다. second_factor 의 값이 on 일 경우, 사용자는 여러 장치 유형 중에서 선택할 수 있는 옵션을 가집니다.
사용자가 tsh login 을 실행할 때 MFA 챌린지를 제공합니다.

Teleport 환경에서 SSO를 활성화한 경우, 로그인 시 MFA 챌린지는 로컬 사용자에게만 적용되지만 IdP가 자체 MFA 검사를 적용할 수 있습니다.

Warning

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

기존 사용자가 MFA 장치를 등록했음을 확인할 때까지 second_factor 를 optional 로 설정하십시오.
tctl users reset <account> 명령을 실행하여 사용자가 MFA 장치를 포함한 새로운 자격 증명을 입력하도록 강제하십시오.

리소스에 접근할 때마다 MFA 챌린지 제시하기

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

모든 사용자에 대해 세션별 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

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

SSO 사용자가 있는 경우, 세션별 MFA의 이점을 활용하려면 Teleport에 MFA 장치를 추가해야 합니다.

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

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

이중 승인은 Teleport의 접근 플러그인(예: Slack, JIRA, PagerDuty)을 사용하여 사용자가 역할을 요청했다고 검토자에게 알립니다. SAML 또는 OIDC 커넥터가 필요한 접근 플러그인에서는 Teleport의 Cloud 또는 Enterprise 버전을 활성화해야 합니다.

다음 두 개의 동적 리소스를 적용하여 이중 승인을 설정할 수 있습니다:

검토자
검토 받는 사람

검토자

일부 사용자가 다른 사용자의 역할 상승 요청을 검토하도록 허용하려면 다음과 유사한 동적 리소스를 적용하십시오:

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 필드는 reviewee 역할을 가진 사용자가 요청할 수 있는 다른 역할의 이름을 나열합니다. 검토 받는 사람이 이러한 역할 중 하나에 접근을 요청하면, Teleport는 접근 플러그인을 통해 검토자에게 알립니다. spec.allow.requests.roles.thresholds 필드는 요청을 승인하거나 거부하는 데 필요한 검토 수를 나타냅니다.

자동으로 일부 역할 요청 방지하기

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

spec.deny 필드는 이전에 설명한 spec.allow 필드와 같은 속성을 가질 수 있지만, 이 필드는 행동을 활성화하는 대신 비활성화합니다. 예를 들어, spec.deny.requests.roles 필드는 사용자가 요청할 수 없는 역할 목록입니다. Teleport는 접근 요청을 실행할 때 deny 규칙을 allow 규칙보다 우선시합니다.

예를 들어, 우리는 사용자 myuser 를 다음 템플릿을 사용하여 정의한 user 역할에 할당했습니다:

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

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

tsh request create --roles=admin

그러나 Auth 서비스는 요청을 거부합니다.

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

allow 또는 deny 규칙 내의 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 에 필수로 만들기