인포레터에서 최신 DevOps 트렌드를 격주로 만나보세요!
IdP 손상에 대비하여 클러스터 강화하기
이 가이드는 귀하의 아이덴티티 인프라를 강화하고 IdP 약점과 관련된 위험을 완화하는 데 도움을 주기 위한 것입니다.
IdP 손상은 공격자가 귀하의 아이덴티티 관리 시스템에 무단으로 액세스할 때 발생하며, 이로 인해 합법적인 사용자를 가장하거나, 권한을 상승시키거나, 민감한 정보에 접근할 수 있게 됩니다. 이는 소프트웨어 취약점을 악용하거나, 자격 증명을 도용하거나, 사회 공학 공격과 같은 다양한 수단을 통해 발생할 수 있습니다.
많은 조직이 Single Sign-On (SSO) 및 Multi-Factor Authentication (MFA)과 같은 기본 보안 조치를 구현했지만, 이러한 조치만으로는 IdP를 겨냥한 정교한 공격으로부터 충분히 보호되지 않을 수 있습니다. 공격자들은 끊임없이 기술을 발전시키고 있으며, 전통적인 보안 조치는 제한 사항이나 취약점을 가질 수 있습니다.
IdP 손상에 대한 방어력을 높이기 위해, 다음과 같은 포괄적인 보안 조치를 구현할 것을 권장합니다.
클러스터 전체에 WebAuthn 설정하기
WebAuthn 표준을 사용하여 전체 인프라에서 강력하고 피싱 저항 인증을 구현하세요. WebAuthn은 W3C 표준이며 FIDO2의 일부로, 웹 인증을 위한 공개 키 암호화를 가능하게 합니다. Teleport는 Teleport에 로그인할 때 (tsh login 또는 웹 UI를 통해) 및 SSH 노드 또는 Kubernetes 클러스터에 접근할 때 WebAuthn을 다단계 인증으로 지원합니다. 하드웨어 키(예: YubiKeys, SoloKeys) 및 Touch ID와 Windows Hello와 같은 생체 인증기와 호환됩니다.
전제 조건
-
실행 중인 Teleport 클러스터 또는 Teleport Cloud, 버전 16 이상. Teleport를 시작하려면 가입하여 무료 평가판을 받으세요.
-
tctl
관리 도구 및tsh
클라이언트 도구.tctl
및tsh
다운로드에 대한 지침은 설치를 방문하세요. -
YubiKey 또는 SoloKey와 같은 WebAuthn 하드웨어 장치
-
연결이 가능한지 확인하기 위해
tsh login
으로 로그인한 다음, 현재 자격 증명을 사용하여tctl
명령어를 실행할 수 있는지 확인하십시오.예를 들어:
tsh login --proxy=teleport.example.com --user=email@example.comtctl status클러스터 teleport.example.com
버전 17.0.0-dev
CA 핀 sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
클러스터에 연결할 수 있고
tctl status
명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 후속tctl
명령어를 실행할 수 있습니다.
자신의 Teleport 클러스터를 호스팅하는 경우, Teleport Auth Service를 호스팅하는 컴퓨터에서 전체 권한으로tctl
명령어를 실행할 수도 있습니다.
1/3단계. WebAuthn 지원 활성화
WebAuthn는 기본적으로 비활성화되어 있습니다. WebAuthn 지원을 활성화하려면 Teleport 구성을 다음과 같이 업데이트하세요:
cluster_auth_preference
리소스를 편집합니다:
tctl edit cap
cluster_auth_preference
정의를 다음 내용을 포함하도록 업데이트하세요:
kind: cluster_auth_preference
version: v2
metadata:
name: cluster-auth-preference
spec:
type: local
# WebAuthn 지원을 활성화하려면 이 필드를 'on', 'optional' 또는 'webauthn'으로 설정합니다.
second_factor: "on"
webauthn:
# 필수, 프록시 웹 주소로 교체 (example.com, example.teleport.sh).
# rp_id는 Teleport Proxy Service의 공개 도메인으로, 프로토콜
# (https://) 및 포트 번호를 *제외*합니다.
rp_id: example.com
# 선택 사항, attestation_allowed_cas는 선택적 허용 목록
#의 인증 기관입니다.
attestation_allowed_cas:
# 항목은 인증서 파일의 경로일 수 있습니다:
- "/path/to/allowed_ca.pem"
# 항목은 인라인 인증서일 수도 있습니다:
- |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
# 선택 사항, attestation_denied_cas는 선택적 거부 목록
#의 인증 기관입니다.
attestation_denied_cas:
# 항목은 인증서 파일의 경로일 수 있습니다:
- "/path/to/denied_ca.pem"
# 항목은 인라인 인증서일 수도 있습니다:
- |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
파일을 저장하고 종료합니다. tctl
이 원격 정의를 업데이트합니다:
cluster auth preference has been updated
webauthn
필드 정의
rp_id
는 Teleport Proxy Service의 공개 도메인으로, 프로토콜(https://
)과 포트 번호를 제외합니다.
attestation_allowed_cas
는 장치 검증을 위한 OPTIONAL 인증 기관 허용 목록(로컬 파일 경로 또는 인라인 PEM 인증서 문자열)입니다.
이 필드는 신뢰하는 장치 모델과 공급업체를 제한할 수 있게 해줍니다. 목록에 없는 장치는 등록 시 거부됩니다. 기본적으로 모든 장치가 허용됩니다. 만약 증명이 필요하다면, 문제 있는 장치를 금지하기 위해 attestation_denied_cas
를 사용하는 것을 고려하십시오.
attestation_denied_cas
는 장치 검증을 위한 OPTIONAL 인증 기관 금지 목록(로컬 파일 경로 또는 인라인 PEM 인증서 문자열)입니다.
이 필드는 특정 장치 모델과 공급업체를 금지하고, 다른 모든 장치를 허용할 수 있게 해줍니다(단, attestation_allowed_cas
를 통과해야 합니다). 이 목록에 있는 장치는 등록 시 거부됩니다. 기본적으로 금지된 장치는 없습니다.
2/3단계. 사용자가 WebAuthn 장치 등록
사용자는 tsh
를 사용하여 여러 WebAuthn 장치를 등록할 수 있습니다:
tsh mfa add장치 유형 선택 [TOTP, WEBAUTHN]: webauthn
장치 이름 입력: desktop yubikey
*등록된* 보안 키를 터치하거나 *등록된* OTP 장치의 코드를 입력하십시오:
*새로운* 보안 키를 터치하십시오
MFA 장치 "desktop yubikey"가 추가되었습니다.
3/3단계. WebAuthn을 사용하여 로그인
WebAuthn 장치가 등록되면, 사용자는 로그인 시 이를 요구받게 됩니다:
tsh login --proxy=example.teleport.shTeleport 사용자 codingllama의 비밀번호를 입력하십시오:
보안 키를 터치하거나 OTP 장치의 코드를 입력하십시오:
> 프로필 URL: https://example.teleport.sh
로그인한 사용자: codingllama
클러스터: example.teleport.sh
역할: access, editor, reviewer
로그인: codingllama
Kubernetes: enabled
유효 기간: 2021-10-04 23:32:29 -0700 PDT [12시간 유효]
확장 기능: permit-agent-forwarding, permit-port-forwarding, permit-pty
Note
Teleport에 로그인할 때 WebAuthn은 로컬 사용자에게만 필요합니다. SSO 사용자는 SSO 제공자에서 다단계 인증을 구성해야 합니다.
세션별 MFA 구성
초기 로그인뿐만 아니라 각 세션에 대해 다단계 인증이 필요하도록 설정하여 지속적인 보안을 유지하십시오. Teleport의 세션별 MFA는 디스크 상의 인증서가 손상되는 경우로부터 보호하여 보안을 강화합니다. 새로운 SSH, Kubernetes, 데이터베이스 또는 데스크탑 세션을 시작할 때 추가 MFA 검사를 요구합니다.
Teleport는 새로운:
- SSH 연결(단일
tsh ssh
호출, 웹 UI SSH 세션 또는 Teleport Connect SSH 세션) - Kubernetes 세션(단일
kubectl
호출) - 데이터베이스 세션(단일
tsh db connect
호출) - 애플리케이션 세션
- 데스크탑 세션
시 추가 다단계 인증 검사가 필요합니다.
세션별 MFA 외에도 SSO 제공자에서 로그인 MFA를 활성화하고 모든 로컬 Teleport 사용자에 대해 보안을 향상시키십시오.
모든 역할에 대한 MFA 검사를 시행하려면 클러스터 인증 구성을 편집하십시오:
cluster_auth_preference
리소스를 편집합니다:
tctl edit cap
리소스에 다음 내용을 포함하고 있는지 확인하십시오:
kind: cluster_auth_preference
metadata:
name: cluster-auth-preference
spec:
require_session_mfa: true
version: v2
편집기에서 파일을 저장하고 닫아 변경 사항을 적용하십시오.
역할별
특정 역할에 대한 MFA 검사를 시행하기 위해, 역할을 다음과 같이 업데이트하십시오:
kind: role
version: v7
metadata:
name: example-role-with-mfa
spec:
options:
# 이 역할에 대한 세션별 MFA 요구
require_session_mfa: true
allow: ...
deny: ...
클러스터 전체 기기 신뢰 구현
조직 전반에 걸쳐 신뢰할 수 있는 기기를 검증하고 관리하는 시스템을 개발하여, 알려지지 않았거나 손상된 기기에서의 무단 접근 위험을 줄입니다. 기기 신뢰는 보호된 리소스에 접근하기 위해 신뢰할 수 있는 기기를 사용하도록 요구함으로써 보안의 추가 계층을 추가하며, 사용자 아이덴티티 및 역할 시행을 보완합니다. 이는 클러스터 전체 또는 RBAC를 통해 구성할 수 있습니다. 지원되는 리소스에는 애플리케이션(역할 기반만 해당), SSH 노드, 데이터베이스, Kubernetes 클러스터, 첫 MFA 기기 등록이 포함됩니다. 후자는 손상된 IdP를 통해 신규 사용자가 자동으로 프로비저닝되는 것을 방지하는 데 도움이 됩니다.
기계 ID 및 기기 신뢰
현재 기계 ID 및 기기 신뢰를 지원하지 않습니다. 기계 ID로 가장한 역할에 대해 또는 클러스터 전체로 기기 신뢰를 요구하면, 기계 ID로 생성된 자격 증명을 리소스에 연결하는 데 사용할 수 없습니다.
우회 방법으로 역할별로 기기 신뢰 시행을 구성하고, 기계 ID를 사용하여 가장할 역할에는 필요하지 않도록 설정하십시오.
필수 조건
- macOS 장치를 등록하려면 다음이 필요합니다:
- 서명되고 공증된
tsh
바이너리. macOS tsh 설치 프로그램 다운로드.
- 서명되고 공증된
- Windows 장치를 등록하려면 다음이 필요합니다:
- TPM 2.0이 포함된 장치.
- 관리자 권한이 있는 사용자. 이는 등록 과정에서만 필요합니다.
tsh
v13.1.2 이상. Windows tsh 설치 프로그램 다운로드.
- Linux 장치를 등록하려면 다음이 필요합니다:
- TPM 2.0이 포함된 장치.
- /dev/tpmrm0 장치를 사용할 수 있는 권한이 있는 사용자 (일반적으로 사용자를
tss
그룹에 할당하여 확인합니다). tsh
v15.0.0 이상. Linux용 tsh 설치.
- 웹 UI 세션을 인증하려면 Teleport Connect가 필요합니다.
tctl
도구는 기기 인벤토리를 관리하는 데 사용됩니다. 기기 관리자는 기기를 관리하고, 새 기기를 인벤토리에 추가하며 더 이상 사용되지 않는 기기를 제거하는 책임이 있습니다.
자체 등록: v13.3.5+
미리 설정된 editor
또는 device-admin
역할(버전 v13.3.6부터)을 가진
사용자는 다음 명령을 사용하여 기기를 한 번에 등록하고 등록할 수 있습니다:
code $ tsh device enroll --current-device
1/3단계. 신뢰할 수 있는 기기 등록
기기를 등록하기 전에 먼저 기기를 등록해야 합니다. 기기를 등록하려면 먼저 시리얼 번호를 확인해야 합니다.
tsh
를 사용하여 기기 시리얼 번호를 가져옵니다(등록하려는 기기에서 실행해야 함):
tsh device asset-tagC00AA0AAAA0A
시리얼 번호는 Apple 메뉴 -> "이 Mac 정보 보기" -> "시리얼 번호" 아래에서 확인할 수 있습니다.
Windows 및 Linux 기기는 제조업체의 구성에 따라 여러 개의 시리얼 번호를 가질 수 있습니다.
Teleport는 다음 중에서 가장 먼저 사용 가능한 값을 선택합니다:
- 시스템 자산 태그
- 시스템 시리얼 번호
- 메인보드 시리얼 번호
Teleport가 선택한 값을 확인하려면, 다음 명령을 실행하십시오:
tsh device asset-tagC00AA0AAAA0A
등록하려는 기기의 시리얼 번호로 C00AA0AAAA0A를 바꾸고 tctl devices add
명령을 실행하십시오:
tctl devices add --os='macos' --asset-tag='C00AA0AAAA0A'기기 C00AA0AAAA0A/macos가 인벤토리에 추가되었습니다
기기가 등록되었는지 확인하려면 tctl
을 사용하십시오:
tctl devices ls자산 태그 OS 등록 상태 기기 ID------------ ----- ------------- ------------------------------------C00AA0AAAA0A macOS 미등록 9cdfc0ad-64b7-4d9c-this-is-an-example
2/3단계. 장치 등록 토큰 만들기
등록된 장치는 등록 세례를 거친 후 신뢰하는 장치가 됩니다. 장치를 등록하기 위해서는 장치 등록 토큰이 필요합니다. 이 토큰은 장치 관리자가 생성하고, 오프밴드에서 등록을 수행하는 사람에게 전송됩니다(예: 기업 채팅을 통해).
등록 토큰을 생성하려면 아래 명령어를 실행하십시오. 여기서 --asset-tag
는 등록하고자 하는 장치의 일련 번호입니다:
tctl devices enroll --asset-tag="C00AA0AAAA0A"장치 "C00AA0AAAA0A" 에서 아래 명령어를 실행하여 등록합니다:tsh device enroll --token=AAAAAAAAAAAAAAAAAAAAAAAA-this-is-an-example
3/3단계. 신뢰하는 장치 등록
위에서 지정한 장치를 사용하여 등록 세례를 수행하려면, tctl devices enroll
에서 출력된 명령어를 입력하십시오:
tsh device enroll --token=AAAAAAAAAAAAAAAAAAAAAAAA-this-is-an-example장치 "C00AA0AAAA0A"/macOS 등록됨tsh logouttsh login --proxy=teleport.example.com --user=myuser # 새로운 인증서 가져오기Teleport 사용자 myuser 의 비밀번호를 입력하십시오:보안 키를 누르십시오보안 키 터치 감지됨> 프로필 URL: teleport.example.com:443 로그인한 사용자: myuser 클러스터: teleport.example.com 역할: access, editor 로그인: myuser Kubernetes: 사용 가능 유효 기간: 2023-06-23 02:47:05 -0300 -03 [12시간 유효] 확장 프로그램: teleport-device-asset-tag, teleport-device-credential-id, teleport-device-id
teleport-device-*
확장이 존재한다는 것은 장치가 성공적으로 등록되고 인증되었음을 보여줍니다. 위의 장치는 이제 신뢰하는 장치입니다.
자동 등록
여러 사용자에게 등록 토큰을 배포하는 것은 어려울 수 있습니다. 이를 해결하기 위해 Teleport는 자동 등록을 지원합니다. 자동 등록이 활성화되면 사용자의 다음 Teleport (tsh
) 로그인 시 사용자의 장치가 자동으로 등록됩니다.
자동 등록이 작동하려면 다음 조건이 충족되어야 합니다:
- 장치가 등록되어 있어야 합니다. 등록은 수동일 수 있으며, Jamf Pro 통합과 같은 통합을 통해 수행될 수 있습니다.
- 클러스터 설정에서 자동 등록이 활성화되어 있어야 합니다.
1/2단계. 클러스터 설정에서 자동 등록 활성화
tctl edit cluster_auth_preference
를 사용하여 동적 구성 리소스를 수정하십시오:
kind: cluster_auth_preference
version: v2
metadata:
name: cluster-auth-preference
spec:
# ...
device_trust:
mode: "required"
+ auto_enroll: true
2/2단계. 로그아웃 후 다시 로그인
활성화되면, Teleport에 장치가 등록된 사용자는 다음 로그인 시 장치가 Teleport에 등록됩니다.
tsh logout모든 사용자가 로그아웃되었습니다.tsh login --proxy=teleport.example.com --user=myuserTeleport 사용자 myuser 의 비밀번호를 입력하십시오:보안 키를 누르십시오보안 키 터치 감지됨> 프로필 URL: teleport.example.com:443 로그인한 사용자: myuser 클러스터: teleport.example.com 역할: access, editor 로그인: myuser Kubernetes: 사용 가능 유효 기간: 2023-06-23 02:47:05 -0300 -03 [12시간 유효] 확장 프로그램: teleport-device-asset-tag, teleport-device-credential-id, teleport-device-id
teleport-device-*
확장이 존재한다는 것은 장치가 성공적으로 등록되고 인증되었음을 보여줍니다.
관리 작업에 MFA 요구하기
민감한 관리 작업에 대한 보안 계층을 추가하려면 이러한 고급 권한 작업에 다단계 인증(MFA)을 요구하십시오. Teleport는 모든 클라이언트(tctl, tsh, Web UI 및 Connect)에서 관리 작업에 대해 추가 MFA 확인을 강제합니다. 이 기능은 어떤 관리 작업 전에 사용자 신원을 즉시 다시 확인함으로써 추가 보안 계층을 추가하여 타협된 관리 계정으로 인한 위험을 완화합니다.
이러한 고급 보안 조치를 채택함으로써 IdP 타협에 대한 강력한 방어력을 구축하고 조직의 공격 표면을 크게 줄일 수 있습니다. 다음 섹션에서는 이러한 권장 사항에 대해 더 깊이 파고들어 구현 및 모범 사례에 대한 단계별 지침을 제공할 것입니다.
관리 작업에 대한 MFA가 활성화되면, tctl auth sign
으로 생성된 사용자 인증서는
추가 MFA 검증으로 인해 자동화에 적합하지 않게 됩니다.
자동화된 워크플로우를 위해 인증서를 발급할 때 머신 ID를 사용하는 것이 좋습니다. 이는 MFA 체크의 적용을 받지 않는 역할 가장을 사용합니다.
슈퍼 관리자 역할을 사용하여 인증 서비스 인스턴스에서 직접 tctl auth sign
으로 생성된 인증서는
레거시 자체 호스팅 설정을 지원하기 위해 MFA 체크의 적용을 받지 않습니다.
전제 조건
- 연결이 가능한지 확인하기 위해
tsh login
으로 로그인한 다음, 현재 자격 증명을 사용하여tctl
명령어를 실행할 수 있는지 확인하십시오. 예를 들어:클러스터에 연결할 수 있고tsh login --proxy=teleport.example.com --user=email@example.comtctl status클러스터 teleport.example.com
버전 17.0.0-dev
CA 핀 sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
tctl status
명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 후속tctl
명령어를 실행할 수 있습니다.
자신의 Teleport 클러스터를 호스팅하는 경우, Teleport Auth Service를 호스팅하는 컴퓨터에서 전체 권한으로tctl
명령어를 실행할 수도 있습니다. - 이 클러스터에서 WebAuthn 구성됨
- YubiKey 또는 SoloKey와 같은 다단계 하드웨어 장치
- WebAuthn 지원이 있는 웹 브라우저 (Teleport Web UI에서 SSH 또는 데스크탑 세션을 사용하는 경우).
WebAuthn이 유일한 다단계 방식으로 허용되는 클러스터에 대해 MFA가 자동으로 강제됩니다.
향후 주요 버전에서 Teleport는 더 넓은 범위의 클러스터 구성에 대해 관리 작업에 대한 MFA를 강제할 수 있습니다.
관리 작업의 예는 다음과 같으며, 이에 국한되지 않습니다:
- 사용자 계정 재설정 또는 복구
- 새로운 사용자 초대
- 클러스터 구성 리소스 업데이트
- 접근 관리 리소스 수정
- 접근 요청 승인
- 새로운 조인 토큰 생성
- 가장
- 머신 ID를 위한 새로운 봇 생성
이는 사용자를 디스크의 Teleport 인증서 타협으로부터 보호하는 고급 보안 기능입니다.
1/2단계. 리소스 편집
cluster_auth_preference
리소스를 편집하십시오:
tctl edit cap
cluster_auth_preference
정의를 업데이트하여 다음 내용을 포함합니다:
kind: cluster_auth_preference
version: v2
metadata:
name: cluster-auth-preference
spec:
type: local
# webauthn을 유일한 다단계 방식으로 허용하려면 이 필드를 'webauthn'으로 설정하십시오.
second_factor: "webauthn"
webauthn:
rp_id: example.com
2/2단계. 파일 저장 및 종료
tctl
명령어가 원격 정의를 업데이트합니다:
cluster auth preference가 업데이트되었습니다.
다음 단계
추가 클러스터 강화 조치를 보려면:
- 비밀번호 없는 인증: 비밀번호와 사용자 이름 없이 인증 제공.
- 잠금: 활성 사용자 세션 또는 호스트에 대한 접근 잠금.
- 조정 세션: 세션 감사자를 요구하고 세밀한 라이브 세션 접근을 허용.
- 하드웨어 키 지원: 하드웨어 기반 개인 키 사용 강제.