InfoGrab Docs

공격의 영향 범위 줄이기

요약

Teleport는 사용자에게 심층 방어를 실천하도록 권장하여 공격자가 부분적으로 성공하더라도 인프라의 모든 구성 요소가 공격에 안전하도록 합니다. To check that you can connect to your Teleport cluster, sign in with tsh login, then verify that you can run tctl commands using your current crede...

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

To check that you can connect to your Teleport cluster, sign in with tsh login, then verify that you can run tctl commands using your current credentials.

For example, run the following command, assigning to the domain name of the Teleport Proxy Service in your cluster and to your Teleport username:

$ tsh login --proxy= --user=
$ tctl status
# Cluster  (=teleport.url=)
# Version  (=teleport.version=)
# CA pin   (=presets.ca_pin=)

If you can connect to the cluster and run the tctl status command, you can use your current credentials to run subsequent tctl commands from your workstation. If you host your own Teleport cluster, you can also run tctl commands on the computer that hosts the Teleport Auth Service for full permissions.

리소스에 접근하는 모든 시도에 대해 MFA 챌린지 제시#

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

Teleport 환경에 따라 모든 사용자에 대해 세션별 MFA를 활성화하려면 다음을 수행합니다:

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 를 사용하여 동적 리소스를 생성합니다.

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는 접근 요청을 실행할 때 allow 규칙보다 deny 규칙에 우선순위를 부여합니다.

예시로 다음 템플릿을 사용하여 정의한 user 역할에 myuser를 할당했습니다:

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

allow 또는 deny 규칙 내의 claims_to_roles 필드는 사용자의 traits를 요청이 허용되거나 금지된 roles에 매핑합니다. 이 경우 {{regexp.not_match(\"admin\")}} 템플릿 함수를 사용하여 administrator 또는 admins와 같은 값을 가진 groups 트레이트가 없는 모든 사용자가 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에게 일시적으로 상승된 권한을 부여할 수 있습니다.

다음 단계#

가이드#

배경 읽기#

  • 인증 커넥터
  • Proxy Service
  • Auth Service
  • 이 가이드에서 설명한 역할들은 internal 트레이트를 사용하며, Teleport는 이를 Teleport 로컬 사용자 데이터베이스의 값으로 교체합니다. Teleport 역할에서 변수 확장이 어떻게 작동하는지에 대한 자세한 내용은 접근 제어 참조를 참조하세요.

공격의 영향 범위 줄이기

원문 보기
요약

Teleport는 사용자에게 심층 방어를 실천하도록 권장하여 공격자가 부분적으로 성공하더라도 인프라의 모든 구성 요소가 공격에 안전하도록 합니다. To check that you can connect to your Teleport cluster, sign in with tsh login, then verify that you can run tctl commands using your current crede...

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

To check that you can connect to your Teleport cluster, sign in with tsh login, then verify that you can run tctl commands using your current credentials.

For example, run the following command, assigning to the domain name of the Teleport Proxy Service in your cluster and to your Teleport username:

$ tsh login --proxy= --user=
$ tctl status
# Cluster  (=teleport.url=)
# Version  (=teleport.version=)
# CA pin   (=presets.ca_pin=)

If you can connect to the cluster and run the tctl status command, you can use your current credentials to run subsequent tctl commands from your workstation. If you host your own Teleport cluster, you can also run tctl commands on the computer that hosts the Teleport Auth Service for full permissions.

리소스에 접근하는 모든 시도에 대해 MFA 챌린지 제시#

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

Teleport 환경에 따라 모든 사용자에 대해 세션별 MFA를 활성화하려면 다음을 수행합니다:

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 를 사용하여 동적 리소스를 생성합니다.

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는 접근 요청을 실행할 때 allow 규칙보다 deny 규칙에 우선순위를 부여합니다.

예시로 다음 템플릿을 사용하여 정의한 user 역할에 myuser를 할당했습니다:

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

allow 또는 deny 규칙 내의 claims_to_roles 필드는 사용자의 traits를 요청이 허용되거나 금지된 roles에 매핑합니다. 이 경우 {{regexp.not_match(\"admin\")}} 템플릿 함수를 사용하여 administrator 또는 admins와 같은 값을 가진 groups 트레이트가 없는 모든 사용자가 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에게 일시적으로 상승된 권한을 부여할 수 있습니다.

다음 단계#

가이드#

배경 읽기#

  • 인증 커넥터
  • Proxy Service
  • Auth Service
  • 이 가이드에서 설명한 역할들은 internal 트레이트를 사용하며, Teleport는 이를 Teleport 로컬 사용자 데이터베이스의 값으로 교체합니다. Teleport 역할에서 변수 확장이 어떻게 작동하는지에 대한 자세한 내용은 접근 제어 참조를 참조하세요.