서명 알고리즘 | Teleport 공식 기술 문서 한국판 by 인포그랩

서명 알고리즘

Teleport Auth 서비스는 모든 연결이 인증되고, 권한 부여되고, 암호화될 수 있도록 사용자와 호스트에 SSH 및 TLS 인증서를 발급합니다. 이 페이지에서는 Teleport에서 발급한 각종 인증서를 서명하는 데 사용되는 암호화 서명 알고리즘에 대해 설명합니다.

계속 읽어보시기 바랍니다.

Teleport 17 이전에 생성된 Teleport 클러스터를 구성하여 빠르고 안전한 타원 곡선 키를 사용하도록 설정하세요.
클러스터가 FIPS 호환 서명 알고리즘을 사용하도록 설정하세요.
클러스터가 HSM 또는 KMS와 호환되는 서명 알고리즘을 사용하도록 설정하세요.

서명 알고리즘 모음

Teleport 17 이후에 생성된 새로운 Teleport 클러스터는 대부분의 경우 자동으로 타원 곡선 키를 사용할 것입니다. 이전 버전의 Teleport에서 클러스터를 생성한 경우, 새로운 알고리즘을 선택할 때까지 RSA 키를 계속 사용합니다. 서명 알고리즘 모음을 구성하여 모든 암호화 서명 알고리즘을 제어할 수 있습니다.

`legacy`

legacy 모음은 모든 서명이 2048비트 RSA 키를 기반으로 하는 원래 Teleport 동작을 식별합니다. 17.0.0 이전 버전에서 생성된 Teleport 클러스터는 항상 legacy 모음을 사용하고 있으며, 새로운 버전으로 업그레이드할 때 자동으로 변경되지 않습니다.

사용자가 가능할 때 새 모음 중 하나로 업그레이드하는 것이 좋습니다.

`balanced-v1`

balanced-v1 모음은 17.0.0 이후에 생성된 자가 호스팅 클러스터의 기본 모음입니다. 이는 대부분의 자가 호스팅 사용자에게 권장되는 모음입니다. 이 모음이 구성되면 모든 SSH 인증서에는 Ed25519가 사용되고, 모든 TLS 인증서에는 NIST P-256 곡선을 사용하는 ECDSA가 사용됩니다.

일반적으로 Teleport와 통합되는 많은 서드파티 소프트웨어와의 호환성을 위해 RSA가 여전히 사용됩니다. 여기에는 db 또는 db_client CA에서 발급된 인증서와 Teleport에서 발급된 특정 JSON 웹 토큰(JWT)도 포함됩니다.

`fips-v1`

FIPS 모드에서 Teleport를 배포하는 사용자에게는 fips-v1 모음을 사용하는 것이 권장됩니다. FIPS 모드에서 17.0.0 이후에 생성된 새 클러스터는 기본적으로 이 모음을 사용합니다.

FIPS 186-5는 Ed25519에 대한 승인을 상대적으로 최근(2023년 2월)에 추가했으며, 알고리즘을 사용하는 방법에는 일부 뉘앙스가 있습니다. Teleport에 더 중요한 것은, 우리가 FIPS Go 이진 파일을 컴파일하는 boringcrypto 모듈이 아직 Ed25519를 지원하지 않는다는 것입니다. 이러한 이유로, fips-v1 모음은 balanced-v1 모음을 기반으로 하며 Ed25519를 모두 ECDSA로 대체합니다.

`hsm-v1`

hsm-v1 모음은 HSM 또는 KMS에 인증 기관 키 자료를 유지하기로 선택한 클라우드 고객 및 자가 호스팅 사용자에게 설계되었습니다. 이는 HSM 또는 KMS가 구성된 17.0.0 이후에 생성된 새로운 클러스터의 기본 모음입니다. 이는 17.x+ 버전의 새로운 Teleport Cloud 클러스터의 기본 모음이 될 것입니다.

Teleport의 PKCS#11 HSM 및 클라우드 KMS와의 통합은 아직 Ed25519를 지원하지 않습니다. 이러한 이유로, hsm-v1 모음은 balanced-v1 모음을 기반으로 하며 모든 인증 기관 키에 대해 Ed25519 대신 ECDSA를 사용합니다. 사용자 및 호스트 SSH 키는 여전히 Ed25519를 사용합니다.

구성

클러스터 서명 알고리즘 스위트는 Auth 서비스 구성 파일에서 정적으로 또는 cluster_auth_preference 리소스에서 동적으로 구성할 수 있습니다.

정적 구성

기본적으로 /etc/teleport.yaml 에 저장된 Teleport Auth 서비스 구성 파일에 다음을 추가하십시오.

auth_service:
  authentication:
    signature_algorithm_suite: "balanced-v1"

동적 리소스

cluster_auth_preference 리소스를 편집하십시오:

tctl edit cap

리소스에 다음 내용이 포함되어 있는지 확인하십시오:

kind: cluster_auth_preference
metadata:
  name: cluster-auth-preference
spec:
  signature_algorithm_suite: "balanced-v1"
version: v2

인증 기관

tctl status 명령은 각 Teleport 클러스터의 인증 기관 상태를 표시하며, 각 키 쌍에 사용되는 알고리즘을 포함합니다.

tctl status
Cluster: example.teleport.shVersion: 17.0.0CA pins: sha256:b1419d94442b2b1ba70f967157bf177c7605020c59ee93a10b0e4d3fc526e7df
authority rotation                protocol status algorithm   storage--------- ----------------------- -------- ------ ----------- --------host      standby (never rotated) SSH      active Ed25519     software                                  TLS      active ECDSA P-256 softwareuser      standby (never rotated) SSH      active Ed25519     software                                  TLS      active ECDSA P-256 softwaredb        standby (never rotated) TLS      active RSA 2048    softwaredb_client standby (never rotated) TLS      active RSA 2048    softwareopenssh   standby (never rotated) SSH      active Ed25519     softwarejwt       standby (never rotated) JWT      active ECDSA P-256 softwaresaml_idp  standby (never rotated) TLS      active RSA 2048    softwareoidc_idp  standby (never rotated) JWT      active RSA 2048    softwarespiffe    standby (never rotated) JWT      active RSA 2048    software                                  TLS      active ECDSA P-256 softwareokta      standby (never rotated) JWT      active ECDSA P-256 software

각 인증 기관은 새 Teleport 클러스터를 생성할 때 Auth 서비스가 처음 시작될 때 자동으로 생성됩니다. 클러스터가 이미 생성된 이후 클러스터의 서명 알고리즘 스위트를 변경하면 새로운 사용자 및 호스트 키는 새로운 알고리즘을 사용하지만 각 인증 기관의 키 자료는 자동으로 업데이트되지 않습니다.

기존 인증 기관에 대해 새로운 서명 알고리즘을 사용하려면 각 인증 기관에 대해 CA 회전을 완료해야 합니다. 이는 클러스터에서 신뢰 관계를 업데이트하기 위한 수동 단계가 필요할 수 있습니다. 절차는 CA 회전 가이드에 문서화되어 있습니다. 이 과정은 선택 사항이며 CA 회전을 완료하지 않아도 기존 인증 기관 키로 클러스터는 계속 기능할 것입니다.

알고리즘

다음 표는 각 키 Teleport가 각 스위트에서 생성하는 키 알고리즘을 나열합니다.

키 목적	`legacy`	`balanced-v1`	`fips-v1`	`hsm-v1`
사용자 CA (SSH)	RSA 2048	Ed25519	ECDSA P-256	ECDSA P-256
사용자 CA (TLS)	RSA 2048	ECDSA P-256	ECDSA P-256	ECDSA P-256
호스트 CA (SSH)	RSA 2048	Ed25519	ECDSA P-256	ECDSA P-256
호스트 CA (TLS)	RSA 2048	ECDSA P-256	ECDSA P-256	ECDSA P-256
데이터베이스 CA	RSA 2048	RSA 2048	RSA 2048	RSA 2048
데이터베이스 클라이언트 CA	RSA 2048	RSA 2048	RSA 2048	RSA 2048
OpenSSH CA	RSA 2048	Ed25519	ECDSA P-256	ECDSA P-256
JWT CA	RSA 2048	ECDSA P-256	ECDSA P-256	ECDSA P-256
OIDC IdP CA	RSA 2048	RSA 2048	RSA 2048	RSA 2048
SAML IdP CA	RSA 2048	RSA 2048	RSA 2048	RSA 2048
SPIFFE CA (TLS)	RSA 2048	ECDSA P-256	ECDSA P-256	ECDSA P-256
SPIFFE CA (JWT)	RSA 2048	RSA 2048	RSA 2048	RSA 2048
Okta CA	ECDSA P-256	ECDSA P-256	ECDSA P-256	ECDSA P-256
사용자 SSH	RSA 2048	Ed25519	ECDSA P-256	Ed25519
사용자 TLS	RSA 2048	ECDSA P-256	ECDSA P-256	ECDSA P-256
데이터베이스 클라이언트	RSA 2048	RSA 2048	RSA 2048	RSA 2048
데이터베이스 서버	RSA 2048	RSA 2048	RSA 2048	RSA 2048
호스트 SSH	RSA 2048	Ed25519	ECDSA P-256	Ed25519
호스트 아이덴티티	RSA 2048	ECDSA P-256	ECDSA P-256	ECDSA P-256
MachineID 아이덴티티	RSA 2048	ECDSA P-256	ECDSA P-256	ECDSA P-256
Workload ID SVID	RSA 2048	ECDSA P-256	ECDSA P-256	ECDSA P-256
EC2 인스턴스 연결	Ed25519	Ed25519	ECDSA P-256	Ed25519
Windows Desktop Client	RSA 2048	RSA 2048	RSA 2048	RSA 2048

FAQ

새로운 알고리즘을 지원하지 않는 경우에는 어떻게 하나요?

시도해보고 알려주세요!
우리는 보안, 성능 및 선택한 서명 알고리즘 스위트 간의 균형을 맞추는 것을 목표로 합니다.
앞으로도 legacy 스위트를 계속 사용하는 것은 괜찮으며, 일부 사용자의 환경에서 필요할 수 있다고 예상합니다.

이러한 알고리즘을 어떻게 선택했나요?

Ed25519는 현대적이고, 빠르며, 안전한 알고리즘으로, 작은 키를 가지고 있으며 새로운 SSH 키의 사실상 표준이 되었습니다.
Teleport가 상호작용해야 하는 모든 것과 호환되는 경우에 우리의 선호도입니다.

NIST P-256 곡선을 사용한 ECDSA는 TLS에 널리 사용되며 지원됩니다.
우리는 Ed25519에 대한 좋은 지원이 없을 경우에 이 알고리즘을 사용합니다.
이 알고리즘은 Ed25519와 유사한 속도 및 보안 특성을 갖고 있습니다.

우리는 Ed25519나 ECDSA를 지원하지 않는 제3자 소프트웨어와 상호작용할 때만 RSA를 계속 사용합니다.

특정 Teleport 인증서에 대해 특정 알고리즘을 선택할 수 없는 이유는 무엇인가요?

서명 알고리즘 스위트는 구성 부담을 간소화하기 위해 설계되었습니다.
우리는 Teleport가 수행하는 모든 서명을 수정할 수 있는 100개의 구성 키를 공개하고 싶지 않았습니다.
이러한 방식은 수천 가지의 조합이 생성될 수 있으며, 보안 문제를 초래할 가능성이 있습니다.

내 HSM이 ECDSA 키를 지원하지 않는다면 어떻게 해야 하나요?

ECDSA 키를 지원하지 않는 PKCS#11 HSM을 사용하는 경우, legacy 알고리즘 스위트를 계속 사용하는 것이 좋습니다.

사용자와 호스트가 Ed25519 및/또는 ECDSA 키를 사용해야 할 강한 필요가 있는 경우, hsm-v1 스위트로 전환할 수 있지만, CA 키가 생성될 때 CA가 비 RSA 키를 사용하는 경우 실패할 수 있습니다.
이로 인해 Auth Service가 키 생성 시도 후 오류로 종료될 수 있습니다.
새 CA 키는 새 Auth Service가 시작될 때, CA 회전이 시작될 때 또는 버전 업그레이드 중에 새로운 CA가 추가될 때 생성될 수 있습니다.
이러한 이유로 legacy 알고리즘 스위트를 계속 사용하는 것을 권장합니다.

내 YubiHSM2 인증 키는 ECDSA 키에 대한 기능이 없으면 어떻게 하나요?

우리의 YubiHSM2 가이드에서는 Teleport Auth Service가 YubiHSM2와 인증하는 데 사용될 인증 키를 생성할 것을 권장합니다.
해당 가이드의 원본 예시는 ECDSA 키를 생성하고 서명하는 데 필요한 기능이 없는 인증 키를 생성했습니다.
v17로 업그레이드하거나 알고리즘 스위트를 변경하기 전에, 필요한 기능이 포함된 새 인증 키를 생성하고 Auth Service 구성을 새 키를 사용하도록 업데이트할 것을 권장합니다.
새 인증 키는 기존 CA 키를 여전히 사용할 수 있습니다.

새 인증 키를 yubihsm-shell 로 생성하려면:

$ yubihsm-shell
기본 커넥터 URL 사용: http://localhost:12345
yubihsm> connect
세션 유지 설정이 15초마다 실행되도록 설정되었습니다.

# 새 인증 키를 생성할 수 있는 관리자 인증 키로 세션을 엽니다.
공장 초기화 인증 키는 id:1과 password:password입니다.
이 매개변수를 변경한 경우 적절한 ID와 비밀번호를 사용하세요.
yubihsm> session open 1
비밀번호를 입력하세요:
세션 0이 생성되었습니다.

# Teleport를 위한 새 인증 키를 생성합니다.
yubihsm> put authkey 0 0 "New Teleport Auth Key" 1 generate-asymmetric-key:sign-pkcs:sign-pss:sign-ecdsa:delete-asymmetric-key sign-pkcs:sign-pss:decrypt-pkcs:decrypt-oaep:sign-ecdsa
비밀번호를 입력하세요:
인증 키 0x1a92가 저장되었습니다.

# 새 인증 키와 비밀번호로 세션을 열 수 있는지 확인합니다.
yubihsm> session open 0x1a92
비밀번호를 입력하세요:
세션 1이 생성되었습니다.

auth_service.ca_key_params.pkcs11.pin 또는 auth_service.ca_key_params.pkcs11.pin_path 에서 참조된 파일을 새 인증 키의 ID를 사용하도록 업데이트한 다음, Auth Service를 재시작하세요.

Teleport 원문 보기