InfoGrab Docs

데이터베이스 CA 마이그레이션

요약

Teleport에서 자체 호스팅 데이터베이스는 Teleport Database Service를 통한 mTLS 인증을 활성화하기 위해 인증서로 구성되어야 합니다. Teleport [ db_ca.released_version ]에서는 자체 호스팅 데이터베이스에 대한 CA 교체를 나머지 Teleport 클러스터로부터 분리하기 위해 db 인증 기관(CA)이 도입되었습니다.

Teleport에서 자체 호스팅 데이터베이스는 Teleport Database Service를 통한 mTLS 인증을 활성화하기 위해 인증서로 구성되어야 합니다.

Teleport [ db_ca.released_version ]에서는 자체 호스팅 데이터베이스에 대한 CA 교체를 나머지 Teleport 클러스터로부터 분리하기 위해 db 인증 기관(CA)이 도입되었습니다.

Teleport [ db_client_ca.released_version.v15 ]에서는 Teleport 자체 호스팅 데이터베이스 접근에서 호스트 CA와 클라이언트 CA 모두로 작동하던 Teleport db CA의 역할을 분리하기 위해 db_client CA가 도입되었습니다. db_client CA는 Teleport [ db_client_ca.released_version.v14 ]에도 패치로 추가되었습니다.

db와 db_client CA는 모두 Teleport 업그레이드 후 발생하는 자동 마이그레이션으로 도입되었습니다.

Teleport의 호스트/클라이언트 데이터베이스 CA 분리는 데이터베이스 인스턴스의 개인 키가 침해된 경우 다른 리소스로의 수평 이동 가능성을 제한하기 위한 것입니다.

이 가이드는 이러한 CA가 Teleport에 추가된 이유와 Teleport 클러스터에 대한 보류 중인 마이그레이션을 완료하는 방법에 대한 정보를 제공합니다.

사전 요구 사항#

  • A running Teleport cluster. If you want to get started with Teleport, sign up for a free trial or set up a demo environment.

  • The tctl and tsh clients.

    Installing `tctl` and `tsh` clients

    1. Determine the version of your Teleport cluster. The tctl and tsh clients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at /v1/webapi/find and use a JSON query tool to obtain your cluster version. Replace with the web address of your Teleport Proxy Service:

      $ TELEPORT_DOMAIN=
$ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"

    2. Follow the instructions for your platform to install tctl and tsh clients:

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.

  • db 또는 db_client CA 이전 버전에서 업그레이드된 Teleport 클러스터. Teleport 클러스터가 [ db_client_ca.released_version.v15 ] 이상에서 생성된 경우 db와 db_client CA가 마이그레이션되지 않았으므로 이 가이드가 해당 클러스터에는 적용되지 않습니다.

Teleport db CA 마이그레이션#

Teleport 클러스터의 db CA를 사용하여 자체 호스팅 데이터베이스에 인증서를 발급할 수 있습니다. Teleport Database Service는 기본적으로 db CA가 발급한 인증서를 신뢰하므로 Teleport에서 추가적인 TLS 구성이 필요하지 않아 편리합니다.

또는 외부 CA를 사용하여 자체 호스팅 데이터베이스에 인증서를 발급할 수 있습니다. 이 경우 데이터베이스에 연결할 때 Teleport Database Service가 해당 CA를 신뢰하도록 구성하면 됩니다.

Teleport가 외부 데이터베이스 CA를 신뢰하게 하는 방법? Teleport Database Service `teleport.yaml` 구성 파일에 정의된 정적 데이터베이스의 경우 `tls.ca_cert_file`을 CA의 루트 인증서가 포함된 파일로 설정합니다.

동적 데이터베이스의 경우 spec.tls.ca_cert에 CA의 루트 인증서를 넣습니다.

예제와 자세한 정보는 Teleport로 데이터베이스를 보호하기 위한 구성 참조를 참조하세요.

Teleport [ db_ca.released_version ] 이전에는 Teleport host CA를 사용하여 (tctl auth sign을 통해) 자체 호스팅 데이터베이스에 인증서를 발급했습니다. db CA는 자체 호스팅 데이터베이스 CA 교체를 나머지 Teleport 클러스터로부터 분리하기 위해 도입되었습니다. 클러스터에 연결된 다른 리소스에 영향을 주지 않고 자체 호스팅 데이터베이스에 사용되는 CA를 교체할 수 있어야 한다는 아이디어입니다. 마찬가지로 클러스터의 host CA를 교체할 때 자체 호스팅 데이터베이스에 영향을 미칠 것을 걱정하지 않아도 됩니다.

Teleport [ db_ca.released_version ]으로 업그레이드 후 데이터베이스 접근이 중단되는 것을 방지하기 위해, Teleport 클러스터는 host CA의 복사본으로 db CA를 생성하도록 자동 마이그레이션됩니다.

클러스터가 Teleport [ db_ca.released_version ]으로 업그레이드되었고 Teleport를 사용하여 자체 호스팅 데이터베이스에 인증서를 발급하는 경우, db CA 마이그레이션을 완료했는지 확인해야 합니다. 그렇지 않으면 나중에 어떤 이유로 CA를 하나만 교체하면 이전 CA의 복사본이 여전히 존재하게 됩니다. 이것이 반드시 클러스터에 취약점을 초래하는 것은 아니지만, 교체 후 이전 CA를 유지하는 것은 나쁜 보안 관행입니다.

db CA 마이그레이션을 완료하려면:

  • host CA를 교체하는 것을 권장합니다.
  • db CA를 교체하는 것을 강력히 권장합니다.

Teleport db_client CA 마이그레이션#

Teleport Database Service는 클라이언트 인증서를 사용하여 자체 호스팅 데이터베이스에 자신을 인증해야 합니다. 이를 위해 데이터베이스가 Teleport의 db_client CA를 신뢰하도록 구성해야 합니다. db_client CA가 도입되기 전에는 자체 호스팅 데이터베이스가 클라이언트 인증을 위해 Teleport db CA를 신뢰하도록 구성해야 했습니다.

이전 방식, 즉 클라이언트 연결에 db CA를 신뢰하는 방식에서는 데이터베이스의 개인 키가 침해되고 해당 키에 대한 db 인증서가 발급된 경우 다른 데이터베이스에 접근하는 데 사용될 수 있었습니다.

모든 자체 호스팅 데이터베이스가 개인 키 침해 후 수평 이동에 취약한 것은 아닙니다. 예를 들어 MySQL과 PostgreSQL은 클라이언트의 인증서 주체가 클라이언트의 데이터베이스 사용자와 일치하는지 확인합니다. 다른 데이터베이스는 클라이언트의 인증서가 신뢰받는지만 확인하고 인증서 주체를 데이터베이스 사용자 이름과 일치시키지 않습니다. 예를 들어 Cassandra, ScyllaDB, Redis는 클라이언트 인증서 주체를 확인하지 않습니다. 이 모든 데이터베이스는 성공적인 mTLS 핸드셰이크 후 비밀번호 인증을 요구하도록 구성할 수 있습니다. 그러나 심층 방어를 위해 이러한 데이터베이스는 db_client CA가 발급한 인증서를 제시하는 클라이언트와만 mTLS 핸드셰이크를 해야 합니다.

Teleport 클러스터가 Teleport >=[ db_client_ca.released_version.v14 ] 또는 >=[ db_client_ca.released_version.v15 ]로 업그레이드된 경우, db_client 마이그레이션을 완료했는지 확인해야 합니다. db_client CA 마이그레이션을 완료하려면:

  • db CA를 교체하는 것을 권장합니다.
  • db_client CA를 교체하는 것을 강력히 권장합니다.
  • db_client CA 교체를 완료한 후 데이터베이스의 인증서를 재구성하는 것을 강력히 권장합니다.
db_client CA 교체 후 인증서 재구성

db_client CA 교체 중에 tctl auth sign을 사용하여 데이터베이스의 인증서를 재구성하면, 신뢰할 수 있는 인증서 출력에 이전 CA와 새 CA 인증서가 모두 포함됩니다. 마이그레이션을 완료하려면 교체 후 해당 데이터베이스를 다시 재구성해야 합니다. 그렇게 하면 새 CA만 신뢰하게 됩니다.

db_client CA 교체 중과 후에 각 데이터베이스를 재구성하고 싶지 않고, Teleport를 통해 데이터베이스에 일시적으로 연결성을 잃어도 괜찮다면, db_client CA 교체를 완료하고 이후에 데이터베이스를 재구성하면 됩니다.

1/2. Teleport CA 마이그레이션 확인#

Teleport >=[ db_ca.released_version ]으로 기존 클러스터를 업그레이드하고 업그레이드 이후 host CA와 db CA를 모두 한 번 이상 교체하지 않은 경우, db CA 마이그레이션을 완료해야 합니다.

Teleport >=[ db_client_ca.released_version.v14 ] 또는 >=[ db_client_ca.released_version.v15 ]으로 기존 클러스터를 업그레이드하고 업그레이드 이후 db CA와 db_client CA를 모두 한 번 이상 교체하지 않은 경우, db_client CA 마이그레이션을 완료해야 합니다.

db 또는 db_client CA에 대한 마이그레이션을 완료해야 하는지 확실하지 않은 경우, 중복된 CA를 확인할 수 있습니다. 다음 명령을 사용하여 host, db, db_client CA(이 순서로)에 대한 X.509 인증서 일련 번호를 출력합니다:

$ tctl auth export --type=tls-host | openssl x509 -noout -serial
$ tctl auth export --type=db | openssl x509 -noout -serial
$ tctl auth export --type=db-client | openssl x509 -noout -serial

db CA 일련 번호가 host CA 일련 번호와 일치하면 db CA 마이그레이션을 완료해야 합니다.

db_client CA 일련 번호가 db CA 일련 번호와 일치하면 db_client CA 마이그레이션을 완료해야 합니다.

2/2. CA 교체#

db와 db_client 마이그레이션을 모두 완료해야 하는 경우, host, db, db_client CA 각각을 한 번씩 교체하면 충분합니다. db CA를 두 번 교체할 필요는 없습니다.

host CA를 교체해야 하는 경우, db 또는 db_client CA 교체를 시작하기 전에 해당 교체를 완료하는 것을 권장합니다. host CA 교체와 병행하여 다른 CA를 교체하지 마세요.

데이터베이스 CA 교체는 교체 중에 외부 리소스(자체 호스팅 데이터베이스)에 새 인증서를 구성하는 작업이 포함되어 있어 약간 다릅니다. 데이터베이스 인증서 재구성 단계를 반복하지 않으려면 db와 db_client CA를 동시에 교체할 수 있고(또 그렇게 해야 합니다).

CA 교체에 대한 자세한 내용은 CA 교체 가이드를 참조하세요.

추가 읽기#

데이터베이스 CA 마이그레이션

원문 보기
요약

Teleport에서 자체 호스팅 데이터베이스는 Teleport Database Service를 통한 mTLS 인증을 활성화하기 위해 인증서로 구성되어야 합니다. Teleport [ db_ca.released_version ]에서는 자체 호스팅 데이터베이스에 대한 CA 교체를 나머지 Teleport 클러스터로부터 분리하기 위해 db 인증 기관(CA)이 도입되었습니다.

Teleport에서 자체 호스팅 데이터베이스는 Teleport Database Service를 통한 mTLS 인증을 활성화하기 위해 인증서로 구성되어야 합니다.

Teleport [ db_ca.released_version ]에서는 자체 호스팅 데이터베이스에 대한 CA 교체를 나머지 Teleport 클러스터로부터 분리하기 위해 db 인증 기관(CA)이 도입되었습니다.

Teleport [ db_client_ca.released_version.v15 ]에서는 Teleport 자체 호스팅 데이터베이스 접근에서 호스트 CA와 클라이언트 CA 모두로 작동하던 Teleport db CA의 역할을 분리하기 위해 db_client CA가 도입되었습니다. db_client CA는 Teleport [ db_client_ca.released_version.v14 ]에도 패치로 추가되었습니다.

db와 db_client CA는 모두 Teleport 업그레이드 후 발생하는 자동 마이그레이션으로 도입되었습니다.

Teleport의 호스트/클라이언트 데이터베이스 CA 분리는 데이터베이스 인스턴스의 개인 키가 침해된 경우 다른 리소스로의 수평 이동 가능성을 제한하기 위한 것입니다.

이 가이드는 이러한 CA가 Teleport에 추가된 이유와 Teleport 클러스터에 대한 보류 중인 마이그레이션을 완료하는 방법에 대한 정보를 제공합니다.

사전 요구 사항#

  • A running Teleport cluster. If you want to get started with Teleport, sign up for a free trial or set up a demo environment.

  • The tctl and tsh clients.

    Installing `tctl` and `tsh` clients

    1. Determine the version of your Teleport cluster. The tctl and tsh clients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at /v1/webapi/find and use a JSON query tool to obtain your cluster version. Replace with the web address of your Teleport Proxy Service:

      $ TELEPORT_DOMAIN=
$ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"

    2. Follow the instructions for your platform to install tctl and tsh clients:

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.

  • db 또는 db_client CA 이전 버전에서 업그레이드된 Teleport 클러스터. Teleport 클러스터가 [ db_client_ca.released_version.v15 ] 이상에서 생성된 경우 db와 db_client CA가 마이그레이션되지 않았으므로 이 가이드가 해당 클러스터에는 적용되지 않습니다.

Teleport db CA 마이그레이션#

Teleport 클러스터의 db CA를 사용하여 자체 호스팅 데이터베이스에 인증서를 발급할 수 있습니다. Teleport Database Service는 기본적으로 db CA가 발급한 인증서를 신뢰하므로 Teleport에서 추가적인 TLS 구성이 필요하지 않아 편리합니다.

또는 외부 CA를 사용하여 자체 호스팅 데이터베이스에 인증서를 발급할 수 있습니다. 이 경우 데이터베이스에 연결할 때 Teleport Database Service가 해당 CA를 신뢰하도록 구성하면 됩니다.

Teleport가 외부 데이터베이스 CA를 신뢰하게 하는 방법? Teleport Database Service `teleport.yaml` 구성 파일에 정의된 정적 데이터베이스의 경우 `tls.ca_cert_file`을 CA의 루트 인증서가 포함된 파일로 설정합니다.

동적 데이터베이스의 경우 spec.tls.ca_cert에 CA의 루트 인증서를 넣습니다.

예제와 자세한 정보는 Teleport로 데이터베이스를 보호하기 위한 구성 참조를 참조하세요.

Teleport [ db_ca.released_version ] 이전에는 Teleport host CA를 사용하여 (tctl auth sign을 통해) 자체 호스팅 데이터베이스에 인증서를 발급했습니다. db CA는 자체 호스팅 데이터베이스 CA 교체를 나머지 Teleport 클러스터로부터 분리하기 위해 도입되었습니다. 클러스터에 연결된 다른 리소스에 영향을 주지 않고 자체 호스팅 데이터베이스에 사용되는 CA를 교체할 수 있어야 한다는 아이디어입니다. 마찬가지로 클러스터의 host CA를 교체할 때 자체 호스팅 데이터베이스에 영향을 미칠 것을 걱정하지 않아도 됩니다.

Teleport [ db_ca.released_version ]으로 업그레이드 후 데이터베이스 접근이 중단되는 것을 방지하기 위해, Teleport 클러스터는 host CA의 복사본으로 db CA를 생성하도록 자동 마이그레이션됩니다.

클러스터가 Teleport [ db_ca.released_version ]으로 업그레이드되었고 Teleport를 사용하여 자체 호스팅 데이터베이스에 인증서를 발급하는 경우, db CA 마이그레이션을 완료했는지 확인해야 합니다. 그렇지 않으면 나중에 어떤 이유로 CA를 하나만 교체하면 이전 CA의 복사본이 여전히 존재하게 됩니다. 이것이 반드시 클러스터에 취약점을 초래하는 것은 아니지만, 교체 후 이전 CA를 유지하는 것은 나쁜 보안 관행입니다.

db CA 마이그레이션을 완료하려면:

  • host CA를 교체하는 것을 권장합니다.
  • db CA를 교체하는 것을 강력히 권장합니다.

Teleport db_client CA 마이그레이션#

Teleport Database Service는 클라이언트 인증서를 사용하여 자체 호스팅 데이터베이스에 자신을 인증해야 합니다. 이를 위해 데이터베이스가 Teleport의 db_client CA를 신뢰하도록 구성해야 합니다. db_client CA가 도입되기 전에는 자체 호스팅 데이터베이스가 클라이언트 인증을 위해 Teleport db CA를 신뢰하도록 구성해야 했습니다.

이전 방식, 즉 클라이언트 연결에 db CA를 신뢰하는 방식에서는 데이터베이스의 개인 키가 침해되고 해당 키에 대한 db 인증서가 발급된 경우 다른 데이터베이스에 접근하는 데 사용될 수 있었습니다.

모든 자체 호스팅 데이터베이스가 개인 키 침해 후 수평 이동에 취약한 것은 아닙니다. 예를 들어 MySQL과 PostgreSQL은 클라이언트의 인증서 주체가 클라이언트의 데이터베이스 사용자와 일치하는지 확인합니다. 다른 데이터베이스는 클라이언트의 인증서가 신뢰받는지만 확인하고 인증서 주체를 데이터베이스 사용자 이름과 일치시키지 않습니다. 예를 들어 Cassandra, ScyllaDB, Redis는 클라이언트 인증서 주체를 확인하지 않습니다. 이 모든 데이터베이스는 성공적인 mTLS 핸드셰이크 후 비밀번호 인증을 요구하도록 구성할 수 있습니다. 그러나 심층 방어를 위해 이러한 데이터베이스는 db_client CA가 발급한 인증서를 제시하는 클라이언트와만 mTLS 핸드셰이크를 해야 합니다.

Teleport 클러스터가 Teleport >=[ db_client_ca.released_version.v14 ] 또는 >=[ db_client_ca.released_version.v15 ]로 업그레이드된 경우, db_client 마이그레이션을 완료했는지 확인해야 합니다. db_client CA 마이그레이션을 완료하려면:

  • db CA를 교체하는 것을 권장합니다.
  • db_client CA를 교체하는 것을 강력히 권장합니다.
  • db_client CA 교체를 완료한 후 데이터베이스의 인증서를 재구성하는 것을 강력히 권장합니다.
db_client CA 교체 후 인증서 재구성

db_client CA 교체 중에 tctl auth sign을 사용하여 데이터베이스의 인증서를 재구성하면, 신뢰할 수 있는 인증서 출력에 이전 CA와 새 CA 인증서가 모두 포함됩니다. 마이그레이션을 완료하려면 교체 후 해당 데이터베이스를 다시 재구성해야 합니다. 그렇게 하면 새 CA만 신뢰하게 됩니다.

db_client CA 교체 중과 후에 각 데이터베이스를 재구성하고 싶지 않고, Teleport를 통해 데이터베이스에 일시적으로 연결성을 잃어도 괜찮다면, db_client CA 교체를 완료하고 이후에 데이터베이스를 재구성하면 됩니다.

1/2. Teleport CA 마이그레이션 확인#

Teleport >=[ db_ca.released_version ]으로 기존 클러스터를 업그레이드하고 업그레이드 이후 host CA와 db CA를 모두 한 번 이상 교체하지 않은 경우, db CA 마이그레이션을 완료해야 합니다.

Teleport >=[ db_client_ca.released_version.v14 ] 또는 >=[ db_client_ca.released_version.v15 ]으로 기존 클러스터를 업그레이드하고 업그레이드 이후 db CA와 db_client CA를 모두 한 번 이상 교체하지 않은 경우, db_client CA 마이그레이션을 완료해야 합니다.

db 또는 db_client CA에 대한 마이그레이션을 완료해야 하는지 확실하지 않은 경우, 중복된 CA를 확인할 수 있습니다. 다음 명령을 사용하여 host, db, db_client CA(이 순서로)에 대한 X.509 인증서 일련 번호를 출력합니다:

$ tctl auth export --type=tls-host | openssl x509 -noout -serial
$ tctl auth export --type=db | openssl x509 -noout -serial
$ tctl auth export --type=db-client | openssl x509 -noout -serial

db CA 일련 번호가 host CA 일련 번호와 일치하면 db CA 마이그레이션을 완료해야 합니다.

db_client CA 일련 번호가 db CA 일련 번호와 일치하면 db_client CA 마이그레이션을 완료해야 합니다.

2/2. CA 교체#

db와 db_client 마이그레이션을 모두 완료해야 하는 경우, host, db, db_client CA 각각을 한 번씩 교체하면 충분합니다. db CA를 두 번 교체할 필요는 없습니다.

host CA를 교체해야 하는 경우, db 또는 db_client CA 교체를 시작하기 전에 해당 교체를 완료하는 것을 권장합니다. host CA 교체와 병행하여 다른 CA를 교체하지 마세요.

데이터베이스 CA 교체는 교체 중에 외부 리소스(자체 호스팅 데이터베이스)에 새 인증서를 구성하는 작업이 포함되어 있어 약간 다릅니다. 데이터베이스 인증서 재구성 단계를 반복하지 않으려면 db와 db_client CA를 동시에 교체할 수 있고(또 그렇게 해야 합니다).

CA 교체에 대한 자세한 내용은 CA 교체 가이드를 참조하세요.

추가 읽기#