코더를 위한 보안 인프라 코드(IaC) 시리즈: 안전하지 않은 암호화

현명한 조직들은 인프라를 코드로 관리하는 개념을 적극 도입하고 있으며, 애플리케이션 구축을 넘어 보안 코드를 작성하는 데 있어 여러분과 같은 개발자들의 기여가 매우 중요합니다. 처음에는 먼 길처럼 느껴질 수 있지만, 동료들 사이에서 두각을 나타내기 위해 충분히 도전할 가치가 있는 여정입니다.

Coders Conquer Security 시리즈의 다음 챕터를 시작하기 전에, 민감한 데이터 저장 취약점을 다루는 게임화된 챌린지에 참여해 보세요. 지금 바로 플레이하고 Kubernetes, Terraform, Ansible, Docker, CloudFormation 중 하나를 선택해 보세요.

어떠셨나요? 지식을 더 보완해야 한다면 아래 내용을 읽어보세요.

오늘날 비밀번호, 개인정보, 금융 기록과 같은 중요 데이터를 저장 시 해싱 처리하는 것은 사이버 보안 방어의 핵심입니다. 이는 여러 면에서 최후의 방어선이자 가장 효과적인 보호 수단 중 하나로 작용합니다. 공격자가 다른 방어 체계를 뚫고 중요 파일에 접근하더라도, 데이터가 적절히 해싱되어 저장되어 있다면 공격자에게는 별다른 소용이 없기 때문입니다.

이는 또한 악의적인 내부자에 대한 강력한 2차 방어 수단이 됩니다. 암호화된 파일은 네트워크의 나머지 부분과는 별도의 키나 비밀번호를 사용할 수 있기 때문입니다. 이 경우, 시스템 관리자나 관리자 권한을 탈취한 해커가 보호된 디렉토리에 접근하더라도, 암호화 키가 다른 곳에 보관되어 있다면 그곳에 있는 암호화된 파일을 해독할 수 없습니다.

물론 모든 암호화 보호 방식은 가장 강력한 컴퓨터로도 해독할 수 없는 강력한 암호화 표준을 사용하는 것을 전제로 합니다.

왜 안전하지 않은 암호화가 위험할까요?

컴퓨터 기술 분야에서 강력한 암호화 알고리즘을 만드는 것과 이를 해독하는 능력은 오랫동안 경쟁 관계에 있었습니다. 1977년, 미국 연방 정부는 당시 컴퓨터 성능을 고려할 때 안전하다고 여겨졌던 56비트 알고리즘인 데이터 암호화 표준(DES)을 개발했습니다.

하지만 컴퓨터는 발전했고, 사람들은 컴퓨터를 네트워크로 연결하여 성능을 더욱 높이는 방법을 찾아냈습니다. 1999년, 전자 프론티어 재단(EFF)과 Distributed.net은 협력하여 DES로 보호된 문서의 암호를 단 22시간 만에 공개적으로 해독했습니다. 그 순간부터 DES 암호화로 보호된 모든 문서는 더 이상 안전하지 않게 되었습니다.

믿기 어렵겠지만, 여전히 일부 조직은 중요 파일을 DES 알고리즘이나 이와 유사하게 취약한 암호화 방식으로 보호하고 있습니다. 1999년에는 56비트 암호를 해독하기 위해 분산 네트워크가 필요했지만, 오늘날에는 충분한 성능을 갖춘 독립형 컴퓨터라면 약간의 시간만 투자해도 이를 해독할 수 있습니다. 또한 해커들은 그래픽 처리 장치(GPU)를 대량으로 연결하여 전용 해독 장비를 만들기도 합니다. 이러한 GPU는 해독 작업에 매우 뛰어나며, 비교적 저렴한 비용으로 확보하여 로컬 네트워크로 구성할 수 있습니다.

오늘날 중요 파일을 안전하지 않거나 취약한 암호화 알고리즘으로 보호하기로 선택한다면, 대부분의 해커가 파일을 해독하여 내용을 읽어내는 데는 그리 오랜 시간이 걸리지 않을 것입니다. 데이터 유출 사고가 발생한다면, 충분히 보호되지 않은 파일은 결국 유출될 것이라고 가정해야 합니다.

예를 들어, 다음 Kubernetes 코드 스니펫은 NGINX 인그레스 컨트롤러 수준에서 정보를 보호하기 위해 취약한 암호화 알고리즘을 사용하고 있습니다.

apiVersion: v1
kind: ConfigMap
metadata:
 name: nginx-load-balancer-conf
 namespace: kube-system
data:
 ssl-ciphers: DES-CBC3-SHA
 ssl-protocols: "TLSv1.2"

이 예시에서는 정보를 보호하기 위해 DES 암호화 제품군이 사용되었습니다. 하지만 공격자는 이를 쉽게 해독하여 민감한 정보에 접근할 수 있습니다.

강력한 암호화 알고리즘을 사용하는 것이 권장됩니다. 다음 Kubernetes 예시에서는 NGINX 인그레스 컨트롤러 수준에서 정보를 보호하기 위해 강력한 암호화 제품군을 사용했습니다.

apiVersion: v1
kind: ConfigMap
metadata:
 name: nginx-load-balancer-conf
 namespace: kube-system
data:
 ssl-ciphers: |
   ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
   ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:
   ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
   ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:
   ECDHE-RSA-AES128-SHA256
 ssl-protocols: "TLSv1.2"

이 예시에서는 공격자가 민감한 정보에 접근할 가능성을 차단하기 위해 강력한 암호화 제품군을 사용했습니다.

강력한 암호화로 중요 정보 보호하기

오늘날 거의 해독이 불가능한 강력한 암호화 기술을 사용할 수 있습니다. 2001년, 미국 국립표준기술연구소(NIST)는 DES를 대체하기 위해 새로운 암호화 기술을 개발했습니다. 고급 암호화 표준(AES)이라 불리는 이 기술은 128, 192, 256비트의 세 가지 키 길이를 사용합니다. 256비트 AES 암호화가 가장 안전하지만, 세 가지 방식 모두 현재 기술 수준에서는 사실상 해독이 불가능한 것으로 간주됩니다. 슈퍼컴퓨터를 이용한 테스트 결과, 대부분의 AES 보호 문서를 해독하는 데 수천 년이 걸리는 것으로 나타났습니다.

중요 파일을 적절히 보호하려면 먼저 어떤 파일이 중요한지 식별해야 합니다. 네트워크상의 모든 데이터를 암호화할 필요는 없습니다. 지속적인 암호화 및 복호화 과정으로 인해 작업 속도가 저하될 수 있기 때문입니다. 하지만 인사 기록, 고객 데이터, 금융 정보와 같은 중요 파일은 적절한 보호가 필요합니다. 본질적으로 이는 보안과 시스템 효율성 사이의 균형을 맞추는 작업입니다.

따라서 이러한 데이터는 AES 표준 중 하나로 암호화해야 하며, 절대 유출되어서는 안 될 매우 중요한 정보의 경우 256비트 암호화까지 적용하는 것이 좋습니다.

또 한 가지 고려할 점은 암호화 추가가 사이트에 비밀번호를 추가하는 것과 같다는 사실입니다. 즉, 승인된 사용자가 암호화 키를 관리해야 합니다. 이것이 업무의 병목 현상이 되지 않도록 키 관리 플랫폼을 도입하여 키를 체계적이고 안전하게 관리하는 것을 고려해 보세요. 중앙 집중식 키 관리를 사용하지 않더라도, 모든 키와 비밀번호를 철저히 보호하여 권한 없는 사용자가 가장 중요한 데이터 저장소에 접근하지 못하도록 해야 합니다.

더 많은 정보는 Secure Code Warrior 블로그 페이지에서 확인하여 이 취약점에 대해 알아보고, 다른 보안 결함으로부터 조직과 고객을 보호하는 방법을 살펴보세요. 또한 IaC 챌린지 데모를 체험하여 Secure Code Warrior 교육 플랫폼에서 사이버 보안 기술을 꾸준히 연마하고 최신 상태로 유지할 수 있습니다.