Udemy CKA 강의 정리 143: TLS Basics

해당 내용은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 공부한 내용입니다. 내용을 그대로 번역하기보다는, 제가 이해하기 쉬운 대로 수정한 부분들이 있습니다.

⚠️ 영어 독해가 많이 부족합니다. 틀린 내용이 있으면 알려주시면 감사하겠습니다.

---

이번 강의에서는 TLS 인증서가 무엇인지, TLS 인증서가 필요한 이유, SSH 또는 웹 서버 보안을 위해 인증서를 구성하는 방법에 대한 기본적인 사항을 살펴보겠습니다.

Certificate

인증서는 거래 중에 두 당사자 간의 신뢰를 보장하는 데 사용됩니다. 예를 들어 사용자가 웹 서버에 액세스하려고 할 때 TLS 인증서는 사용자와 서버 간의 통신이 암호화되고 서버가 누구인지 확인합니다.

시나리오를 살펴보겠습니다. 보안 연결이 없으면 사용자가 자신의 온라인 뱅킹 응용 프로그램에 액세스하는 경우 입력한 자격 증명이 일반 텍스트 형식으로 전송됩니다. 네트워크 트래픽을 스니핑하는 해커는 자격 증명을 쉽게 검색하고 이를 사용하여 사용자의 은행 계좌를 해킹할 수 있습니다.

Symmetric Encryption

그것은 분명히 안전하지 않으므로 암호화 키를 사용하여 전송되는 데이터를 암호화해야 합니다. 데이터는 기본적으로 난수와 알파벳의 집합인 키를 사용하여 암호화됩니다. 데이터에 난수를 추가하고 인식할 수 없는 형식으로 암호화합니다.
그런 다음 데이터가 서버로 전송됩니다. 네트워크를 스니핑하는 해커는 데이터를 얻지만 아무 것도 할 수 없습니다.
그런데 데이터를 받는 서버도 마찬가지입니다. 키 없이는 데이터를 해독할 수 없으므로 서버가 메시지를 해독하고 읽을 수 있도록 키 복사본도 서버로 보내야 합니다. 키도 동일한 네트워크를 통해 전송되기 때문에 해커는 이를 스니핑하고 이를 사용하여 데이터를 해독할 수 있습니다.

이를 대칭 암호화라고 합니다. 안전한 암호화 방식이지만 데이터를 암호화하고 복호화하는데 동일한 키를 사용하고, 수신자와 수신자 간에 키를 교환해야 하므로 해커가 키에 접근하여 복호화할 위험이 있습니다. 

Asymmetric Encryption

비대칭 암호화는단일 키를 사용하여 데이터를 암호화하고 해독하는 대신 한 쌍의 키, 개인 키 및 공개 키를 사용합니다.
개인 키와 공개 키라고 부르지만 이 예에서는 이해를 위해 개인 키와 공개 자물쇠라고 생각해봅시다,
나에게만 있는 열쇠는 비공개이고, 자물쇠는 누구나 접근할 수 있으므로 공개입니다. 자물쇠로 데이터를 암호화하면 해당하는 키로만 데이터를 열 수 있습니다.
따라서 키는 항상 안전하게 보호받고 있어야 하며 다른 사람과 공유해서는 안 됩니다. 자물쇠는 공개되어 있지만 개인 키로만 무언가를 잠글 수 있습니다. 공개 자물쇠를 사용하여 무엇을 잠그더라도 개인 키로만 잠금을 해제할 수 있습니다.
웹 서버 예제로 돌아가기 전에 키 쌍을 사용하여 서버에 대한 SSH 액세스를 보호하는 더 간단한 사용 사례를 살펴보겠습니다.

환경에 액세스해야 하는 서버가 있습니다. password는 너무 위험하므로 키 쌍을 사용하기로 결정합니다. private key, public key 쌍을 생성합니다. SSH 키와 명령을 실행하여 이를 수행할 수 있습니다.

ssh-keygen

 

이는 두 개의 파일을 생성합니다. id_rsa는 개인 키이고 id_rsa.pub는 공개 키입니다. 지금은 공개 자믈쇠이지요.

그런 다음 공개 자물쇠로 잠긴 문을 통하는 경우를 제외하고, 서버에 대한 모든 액세스를 잠가 서버를 보호합니다. 일반적으로 공개 키가 있는 항목을 서버의 SSH authorized_keys 파일에 추가하여 수행됩니다.

cat ~/.ssh/authorized_keys

 

SSH를 시도할 때 SSH 명령에서 개인 키의 위치를 지정합니다.

ssh -i id_rsa user1@server1

 

환경에 다른 서버가 있는 경우 어떻게 할까요? 하나의 키 쌍으로 둘 이상의 서버를 보호할 수 있을까요?
공개 자물쇠의 복사본을 만들어 원하는 만큼 많은 서버에 배치할 수 있습니다. 동일한 개인 키를 사용하여 모든 서버에 안전하게 SSH로 연결할 수 있습니다.
다른 사용자가 서버에 액세스해야 하는 경우 어떻게 해야 합니까? 그 유저의 자체 공개 및 개인 키 쌍을 생성해야 합니다. 해당 서버에 액세스할 수 있는 유일한 사람으로서 추가 도어를 생성하고 공개 자물쇠로 잠그고 공개 자물쇠를 모든 서버에 복사하면 이제 다른 사용자가 개인 키를 사용하여 서버에 액세스할 수 있습니다.

웹 서버 예제로 돌아가 봅시다. 보시다시피, 이전 대칭 암호화에서 우리가 겪었던 문제는 데이터를 암호화하는 데 사용된 키가 암호화된 데이터와 함께 네트워크를 통해 서버로 전송되어야 했기 때문에, 해커가 암호를 해독할 키를 얻을 위험이 있습니다. 어떻게든 서버의 키를 안전하게 얻을 수 있다면 어떨까요? 서버에서 키를 안전하게 사용할 수 있게 되면 서버와 클라이언트는 대칭 암호화를 사용하여 서로 안전하게 통신을 계속할 수 있습니다. 클라이언트에서 서버로 대칭 키를 안전하게 전송하기 위해 비대칭 암호화를 사용합니다. 따라서 서버에서 공개 및 개인 키 쌍을 생성합니다

.

아이디어를 얻었으니 앞으로 공개 로그를 공개 키로 사용해보겠습니다. SSH key gen 커맨드는 이전에 SSH용 키 쌍을 생성하는 데 사용되었는데 이번에는 형식이 약간 다릅니다. 여기서 openssl 커맨드를 사용하여 개인 키와 공개 키 쌍을 생성합니다.

사용자가 https를 사용하여 웹 서버에 처음 액세스하면 서버에서 공개 키를 가져옵니다. 해커가 모든 트래픽을 스니핑하고 있으므로 그도 공개 키의 복사본을 얻었다고 가정해 보겠습니다. 우리는 그가 그것으로 무엇을 할 수 있는지 볼 것입니다. 실제 사용자의 브라우저는 서버에서 제공하는 공개 키를 사용하여 대칭 키를 암호화합니다. 이제 대칭 키가 안전합니다. 그런 다음 사용자는 이것을 서버로 보냅니다. 해커도 사본을 얻습니다. 서버는 개인 키를 사용하여 메시지를 해독하고 메시지에서 대칭 키를 검색합니다. 그러나 해커는 수신한 메시지에서 대칭 키를 해독하고 검색할 수 있는 개인 키가 없습니다. 해커는 메시지를 잠그거나 암호화할 수만 있고 메시지를 해독할 수 없는 공개 키만 가지고 있습니다. 대칭 키는 이제 사용자와 서버에서만 안전하게 사용할 수 있습니다. 비대칭 키를 사용하여 데이터를 암호화하고 서로에게 보낼 수 있습니다.

수신자는 동일한 대칭 키를 사용하여 데이터를 해독하고 정보를 검색할 수 있습니다. 해커는 어떤 데이터도 해독할 수 없는 암호화된 메시지와 공개 키를 남깁니다. 비대칭 암호화를 사용하여 대칭 키를 사용자에서 서버로 성공적으로 전송했으며 대칭 암호화를 사용하여 향후의 모든 통신을 보호했습니다. 

해커는 이제 우리의 계정을 해킹할 수 있는 새로운 방법을 찾고 있으므로 우리의 자격 증명을 얻을 수 있는 유일한 방법은 그가 제시하는 양식에 우리가 직접 입력하는 것임을 알게 됩니다. 그래서 그는 은행 웹사이트와 똑같이 생긴 웹사이트를 만듭니다. 디자인도 동일하고 그래픽도 동일한 실제 은행 웹사이트의 복제본입니다. 그는 자신의 서버에서 웹사이트를 호스팅합니다. 그는 당신이 그것이 안전하다고 생각하기를 원하기 때문에 자신의 공개 및 개인 키 쌍 세트를 생성하고 웹 서버에서 구성합니다. 그리고 마지막으로 그는 은행 웹사이트로 가는 요청을 자신의 서버로 라우팅하기 위해 어떻게든 사용자의 환경이나 네트워크를 조정합니다. 브라우저를 열고 웹사이트 주소를 입력하면 매우 친숙한 페이지가 표시됩니다. 이전에 보았던 것과 동일한 은행 로그인 페이지이므로 계속해서 사용자 이름과 password를 입력합니다. 브라우저는 키를 수신하고 암호화된 대칭 키를 보낸 다음 해당 키로 암호화된 자격 증명을 보내고 수신자는 동일한 대칭 키로 자격 증명을 해독합니다. 암호화된 방식으로 안전하게 통신했지만 해커의 서버와 통신했습니다. 자격 증명을 보내자마자 은행의 대시보드와 많이 닮지 않은 대시보드가 표시됩니다.

서버에서 받은 키를 보고 실제 은행 서버에서 보낸 합법적인 키인지 알 수 있다면 어떨까요? 서버가 키를 보낼 때 키를 함께 보내는 것이 아니라 키가 포함된 인증서를 보냅니다. 인증서를 자세히 살펴보면 실제 인증서와 같지만 디지털 형식임을 알 수 있습니다.

여기에는 인증서가 발급된 사람, 해당 서버의 공개 키, 해당 서버의 위치 등에 대한 정보가 있습니다. 모든 인증서에는 이름이 있으며, 인증서가 발급된 사람 또는 주체는 자신의 신원을 확인하는 데 도움이 되는 필드이므로 매우 중요합니다. 웹 서버용인 경우 사용자가 브라우저의 URL에 입력한 내용과 일치해야 합니다. 은행이 다른 이름으로 알려져 있고 사용자가 다른 이름으로도 애플리케이션에 액세스하기를 원하는 경우 이 인증서의 모든 이름을 기본 이름 섹션의 subject 아래에 지정해야 합니다. 하지만 누구나 이와 같은 인증서를 생성할 수 있습니다. 자신이 Google이라고 말하면서 직접 생성할 수 있으며, 이것이 해커가 이 작업에서 수행한 작업입니다. 그는 자신이 은행 웹사이트라는 인증서를 생성했습니다. 그렇다면 인증서를 보고 합법적인지 확인하는 방법은 무엇입니까? 그것이 인증서의 가장 중요한 부분이 작용하는 곳입니다.

누가 인증서에 서명하고 발급했습니까? 인증서를 생성한 경우 직접 서명해야 합니다. 이를 self-signed certificate라고 합니다. 당신이 생성한 인증서를 보는 사람은 누구나 당신이 서명했기 때문에 그것이 안전한 인증서가 아니라는 것을 즉시 알게 될 것입니다. 해커에게 받은 인증서를 자세히 살펴보면 해커가 직접 서명한 가짜 인증서임을 알 수 있습니다. 사실, 우리의 브라우저가 우리를 위해 그렇게 합니다. 모든 웹 브라우저에는 인증서 유효성 검사 메커니즘이 builtin되어 있으며 브라우저 텍스트에서는 서버에서 받은 인증서가 합법적인지 확인하기 위해 유효성을 검사합니다. 고정 인증서로 식별되면 실제로 경고합니다.

그렇다면 웹 브라우저가 신뢰할 수 있는 웹 서버에 대한 합법적인 인증서를 어떻게 생성합니까? 권한이 있는 사람이 인증서에 서명하는 방법은 무엇입니까? 여기서 인증 기관 또는 CA가 나타납니다.

그들은 당신을 위해 인증서에 서명하고 검증할 수 있는 잘 알려진 조직입니다. 잘 알려진 일부는 Symantec, DigiCert, Comodo, GlobalSign 등입니다. 이것이 작동하는 방식은 이전에 생성한 키와 웹 사이트의 도메인 이름을 사용하여 certificate signing a request or CSR를 생성하는 것입니다.

open SSL 커맨드를 사용하여 이 작업을 다시 수행할 수 있습니다. 위 커맨드는 my-bank.csr file을 생성합니다. 이 파일은 서명을 위해 CA로 보내야 하는 인증서 서명 요청인 CSR 파일입니다. 이렇게 생겼습니다.

인증 기관은 우리의 세부 정보를 확인하고 인증서에 서명하고 다시 보냅니다. 이제 브라우저가 신뢰하는 CA에서 서명한 인증서가 있습니다.

해커가 동일한 방식으로 서명된 인증서를 얻으려고 하면 유효성 검사 단계에서 실패하고 CA에서 인증서를 거부합니다. 따라서 그가 호스팅하는 웹사이트에는 유효한 인증서가 없습니다. CA는 다른 기술을 사용하여 귀하가 해당 도메인의 실제 소유자인지 확인합니다.

이제 브라우저가 신뢰하는 CA에서 서명한 인증서가 있습니다. 그러나 브라우저는 CA 자체가 합법적이라는 것을 어떻게 알 수 있습니까? 예를 들어 인증서가 가짜 CA에 의해 서명된 경우입니다.

이 예에서 우리의 인증서는 Symantec에서 서명되었습니다. 브라우저는 시만텍이 유효한 CA이며, 시만텍이라고 주장하는 사람이 아닌 진짜 시만텍이 서명한 인증서라는 사실을 어떻게 알 수 있을까요?

CA 자체에는 일련의 공개 및 개인 키 쌍이 있습니다. CA는 개인 키를 사용하여 인증서에 서명합니다. 모든 CA의 공개 키는 브라우저에 builtin되어 있습니다. 브라우저는 CA의 공개 키를 사용하여 인증서가 실제로 CA 자체에 의해 서명되었는지 확인합니다.

인증서 아래의 웹 브라우저 설정에서 실제로 볼 수 있으며 신뢰할 수 있는 CA 탭 아래에 있습니다. 이제 이들은 은행, 이메일 등과 같이 우리가 방문하는 공개 웹사이트가 합법적인지 확인하는 데 도움이 되는 공개 CA입니다.

그러나 조직 내에서 비공개로 호스팅되는 사이트의 유효성을 검사하는 데 도움이 되지 않습니다. 예를 들어 급여 또는 내부 이메일 애플리케이션에 액세스하기 위해. 이를 위해 자체 사설 CA를 호스팅할 수 있습니다. 여기에 나열된(?) 대부분의 회사는 회사 내에서 내부적으로 배포할 수 있는 CA 서버인 사설 서비스를 제공합니다. 그런 다음 내부 CA 서버의 공개 키를 모든 직원 브라우저에 설치하고 조직 내에서 보안 연결을 설정할 수 있습니다.

요약해 봅시다. 네트워크를 통해 전송되는 메시지를 암호화하려는 이유를 살펴보았습니다. 메시지를 암호화하기 위해 공개 키와 개인 키 쌍으로 비대칭 암호화를 사용합니다. 관리자는 한 쌍의 키를 사용하여 서버에 대한 SSH 연결을 보호합니다. 서버는 한 쌍의 키를 사용하여 트래픽을 보호합니다. 그러나 이를 위해 서버는 먼저 인증서 서명 요청을 CA에 보내고 CA는 개인 키를 사용하여 CSR에 서명합니다. 모든 사용자는 CA의 공개 키 사본을 가지고 있음을 기억하세요. 그런 다음 서명된 인증서가 서버로 다시 전송됩니다. 서버는 서명된 인증서로 웹 애플리케이션을 구성합니다.

사용자가 웹 애플리케이션에 액세스할 때마다 서버는 먼저 공개 키와 함께 인증서를 보냅니다. 사용자 또는 사용자의 브라우저는 인증서를 읽고 CA의 공개 키를 사용하여 서버의 공개 키를 검증하고 검색합니다. 그런 다음 앞으로 모든 통신에 사용할 대칭 키를 생성합니다. 대칭 키는 서버의 공개 키를 사용하여 암호화되어 다시 서버로 전송됩니다. 서버는 개인 키를 사용하여 메시지를 해독하고 대칭 키를 검색합니다. 대칭 키는 앞으로의 통신에 사용됩니다. 따라서 관리자는 SSH 보안을 위한 키 쌍을 생성합니다. 웹 서버는 https로 웹 사이트를 보호하기 위한 키 쌍을 생성합니다. 인증 기관은 인증서에 서명하기 위해 고유한 key pair 세트를 생성합니다. 그러나 최종 사용자는 단일 대칭 키만 생성합니다. 웹사이트와 신뢰를 구축한 후에는 자신의 사용자 이름과 암호를 사용하여 웹 서버에 인증합니다.

서버의 클라이언트는 서버가 자신이 말하는 사람인지 확인할 수 있었지만 서버는 클라이언트가 자신이 말하는 사람인지 확실히 알 수 없습니다. 이미 TLS로 보안을 설정했으므로 네트워크를 통해서가 아니라 어떤 식으로든 자신의 자격 증명에 액세스하여 사용자를 사칭하는 해커일 수 있습니다. 

서버는 클라이언트가 자신이 말하는 사람인지 확인하기 위해 무엇을 할 수 있을까요? 이를 위해 초기 신뢰 구축의 일부로 서버는 클라이언트에서 인증서를 요청할 수 있습니다. 따라서 클라이언트는 유효한 CA에서 한 쌍의 키와 서명된 인증서를 생성해야 합니다. 그런 다음 클라이언트는 클라이언트가 자신이 말하는 사람인지 확인하기 위해 서버에 인증서를 보냅니다.

이제 웹 사이트에 액세스하기 위해 클라이언트 인증서를 생성한 적이 없다고 생각해야 합니다. TLS 클라이언트 인증서는 일반적으로 웹 서버에서 구현되지 않기 때문입니다. 그렇더라도 모두 호스트 아래에서 구현됩니다. 따라서 일반 사용자는 수동으로 인증서를 생성하고 관리할 필요가 없습니다. 이것이 클라이언트 인증서에 대한 마지막 부분이었습니다.

Public Key Infrastructure

CA, 서버, 사람 및 디지털 인증서 생성, 배포 및 유지 관리 프로세스를 포함한 이 전체 인프라를 공개 키 인프라 또는 PKI라고 합니다.

마지막으로 떠나기 전에 정리할 것이 있습니다. 저는 개인 키와 공개 키에 대해 키와 자물쇠의 비유를 사용해 왔습니다. 자물쇠 혹은 공개 키만 데이터를 암호화할 수 있다는 것은 사실이 아니므로 주의해 주세요. 사실 이들은 쌍을 이룬 키입니다. 둘 중 하나로 데이터를 암호화하고 다른 하나로만 데이터를 해독할 수 있습니다. 하나로 데이터를 암호화하고 같은 것으로 해독할 수 없습니다. 따라서 데이터를 암호화하는 대상에 주의해야 합니다. 개인 키로 데이터를 암호화하는 경우 공개 키를 가진 사람은 누구나 메시지를 해독하고 읽을 수 있음을 기억하세요.

Certificates naming convention

마지막으로 명명 규칙에 대한 간단한 참고 사항을 공유드립니다. 일반적으로 공개 키가 있는 인증서는 crt 또는 pem 확장자이므로 서버입니다. 그리고 개인 키는 일반적으로 확장자가 key, key.pem입니다. 따라서 개인 키에는 일반적으로 확장명이나 인증서 이름에 키라는 단어가 포함되어 있다는 점을 기억하세요. 키라는 단어가 없는 것은 일반적으로 공개 키 또는 인증서입니다.