역사적으로 기획자가 솔루션의 품질을 과신하여 수많은 실패가 발생했습니다. 침몰할 수 없었던 타이타닉호나 제2차 세계대전의 난공불락의 매기노트 라인처럼, 하나의 솔루션에 지나친 자신감을 가졌을 때 끔찍한 재앙이 반복해서 발생했습니다.
사이버 보안의 세계에서도 마찬가지입니다. 단일 솔루션으로 사이버 보안을 방어한다면 문제가 생길 수 있습니다.
보안에 대한 단일 솔루션의 위험성
이 글에서는 한 전자상거래 업체에서 이러한 문제가 발생한 구체적인 사례를 살펴보겠습니다. 이 회사는 모바일 앱용 새 로그인 API를 구축했습니다. 모든 인증 요청의 페이로드에 비밀번호를 1024비트 RSA 암호화하도록 하여 보안을 강화했습니다.
이것은 좋은 생각입니다. 결국 인증 정보를 사람이 읽을 수 없기 때문에 중간자 공격을 거의 쓸모없게 만들 수 있습니다. 인증 정보는 Base64로 인코딩되고 RSA로 암호화된 문자열로 나타납니다. 인증 요청이 자체 앱에서 이루어졌기 때문에 꽤 좋은 접근 방식이었습니다. 엄지손가락을 치켜세웁니다.
하지만... 그 이상도 있습니다. 이 보안 조치만으로 충분하다고 생각한 것은 좋은 생각이 아니었습니다. 비밀번호 시도 실패 횟수를 최대로 제한하는 등의 조치로 보안을 계속 개선하는 대신 그냥 출시하기로 결정하고 다른 개발 작업으로 넘어갔습니다.
모든 것이 정상인 것처럼 보이지만, 이 솔루션에는 심각한 결함이 있었습니다. 1024비트 공개 키는 JADX를 사용하여 모바일 앱을 디컴파일하면 쉽게 관찰할 수 있었습니다.
공격자는 공개 키를 로컬 파일에 저장함으로써 원하는 모든 비밀번호를 순환하여 대상의 공개 키에 따라 모두 암호화하고 애초에 인증 엔드포인트를 보호하는 작업을 완전히 취소할 수 있습니다.
이 엔드포인트에는 최대 비밀번호 시도 실패 횟수 제한이 없었기 때문에 원하는 만큼의 비밀번호를 자동으로 검사하는 bash 스크립트를 작성했습니다. 그리고 문제를 입증하기 위해 설정한 간단한 비밀번호 카운트다운을 통해 이 전자상거래 제공업체에 문제를 증명했습니다:
#!/bin/bash |
다음은 제 스크립트의 출력입니다:
Welcome 10 |
자세히 살펴보겠습니다. 에서 for 루프에서 개념 증명을 위해 설정한 비밀번호에 도달하기 위해 어떤 숫자를 입력할지 알려주는 환영 메시지로 시작합니다. 그런 다음 API로 전송될 비밀번호와 후속 암호화된 값을 확인합니다. (제가 이렇게 간단한 비밀번호를 여기서 공개할 거라고는 생각도 못하셨죠?)
마지막으로 비밀번호 확인에 대한 API 응답을 출력합니다. 처음 6번의 시도에서는 실패한 응답을 받았지만, 마침내 다음과 같은 매우 안전한(😉) 비밀번호를 얻었습니다. faster4ward를 사용하면 API는 일반적인 권한 범위로 로그인할 수 있도록 허용합니다.
RSA 암호화 인증 페이로드는 이제 그만...
같은 실수를 피하는 방법
문제를 파악했으니 이제 어떻게 해야 할까요? 우선 이 문제를 발생시킨 근본적인 생각의 실수부터 짚어보겠습니다. 애플리케이션 보안을 위한 만병통치약은 없기 때문에 모든 웹 애플리케이션을 성공적으로 보호하려면 해야 할 일이 많습니다 ! 위의 구체적인 예시에서는 강력한 RSA 암호화 외에도 다른 조치를 취해야 합니다.
- 암호화 키가 안전한지 확인하세요.
- 비밀번호 인증 시도 실패 횟수를 최대로 제한하여 계정을 잠그도록 합니다.
- 요청 속도 제한을 구현합니다.
인터넷에 노출된 시스템의 모든 보안은 심층 방어라는 원칙을 수용해야 합니다: 가장 흥미롭거나 방어가 확실하다고 생각되는 지점뿐만 아니라 웹 사이트의 전체 표면 영역에 걸쳐 여러 계층의 방어를 구축해야 합니다.
다행히도 리노드는 플랫폼에 내장된 많은 훌륭한 보안 기능을 제공하며, 몇 가지 일반적인 공격 벡터를 해결하기 위한 많은 업계 표준이 있습니다. 이러한 솔루션 중 일부는 리노드 계정에 적용되고 일부는 리노드에 직접 적용됩니다. 두 가지 유형의 보호 기능을 모두 살펴보겠습니다.
리노드 계정에 대한 관리자 액세스 보호
누군가 리노드 계정에 침입할 수 있다면 게임 끝입니다. 리노드에 침입하는 것은 사소한 일이 됩니다. 이것이 바로 리노드 계정이 보안을 염두에 두고 만들어진 이유입니다. 기본적으로 모든 Linode 계정은 전화 인증으로 보안을 유지해야 합니다. 또한 리노드는 계정 복구 목적으로 보안 질문과 답변을 구성해야 합니다.
전화 인증 외에도 시간 기반 일회용 비밀번호(TOTP) 인증 코드를 사용하여 2단계 인증을 구성할 수도 있습니다. 계정에 반드시 필요한 것은 아니지만, 2단계 인증은 비밀번호와 보안 질문보다 훨씬 더 안전하며 전화 인증 코드보다 훨씬 더 안전하므로 활성화할 것을 적극 권장합니다.
리노드 비밀번호를 전혀 사용하지 않는 또 다른 수준의 보안을 사용할 수 있습니다. 타사 인증(TPA) 소스를 사용할 수 있습니다. 이 방법을 사용하면 원하는 타사 소스에서 안전한 로그인 방법을 구성할 수 있습니다(현재 Google과 GitHub가 지원됩니다). 이렇게 하면 비밀번호 유출로 인해 리노드 계정에 액세스할 수 없게 될 가능성이 줄어듭니다.
마지막으로 계정을 보호하는 한 가지 방법은 계정의 특정 부분에 액세스할 수 있는 특정 사용자를 설정하는 것입니다. 이렇게 하면 하위 사용자가 내 계정에서 수행할 수 있는 작업에 대해 특정 권한을 설정할 수 있으므로 공격자가 내 계정에 피해를 입힐 가능성을 더욱 줄일 수 있습니다.
인프라의 다양한 부분에 액세스하는 사용자 간에 이러한 문제를 분리하는 것은 좋은 관행입니다. 물론 한 팀으로 구성된 팀이라면 이 방법이 필요하지 않을 수도 있습니다. 하지만 진정한 의미의 업무 분리가 이루어진다면 계정이나 인프라에 대한 무단 변경을 방지할 수 있습니다.
리노드 보안
계정을 보호하는 것도 중요하지만 서버와 인프라를 보호하는 것이 훨씬 더 중요할 수 있습니다. 대부분의 공격자는 호스팅 제공업체가 아닌 인프라를 통해 인프라에 침입하려고 할 것이기 때문입니다. 리노드는 여기서도 여러분을 보호합니다.
시작하기 가장 좋은 곳 중 하나는 Linode 앱 Marketplace 입니다. 서버 게이트에서 악성 트래픽을 차단하기 위해 Haltdos WAF 와 같은 보안 솔루션을 배포해야 하거나 Prometheus + Grafana 설정과 같은 모니터링 스택을 원클릭으로 설치하려는 경우, Marketplace 보다 더 쉽게 스택을 보호하고 모니터링할 수 있는 방법은 없습니다.
타사 앱만 사용할 수 있는 것은 아닙니다. Linode Cloud Firewall 는 클라우드 관리자에서 바로 쉽게 구성할 수 있는 훌륭한 솔루션입니다. Linode Cloud Firewall 와 방화벽을 모두 사용하는 것도 좋은 생각입니다.
또 다른 좋은 방법은 서버를 DDoS 공격으로부터 보호하는 것입니다. Linode를 사용하면 기본적으로 이러한 공격으로부터 전체 인프라를 무료로 방어할 수 있습니다! 구성하기 위해 아무것도 할 필요도 없습니다.
결론
보안에 대해 더 할 말이 많지만 지금은 이 정도면 충분할 것입니다. 결론적으로, 한 가지 문제에 대한 현명한 해결책으로 인해 보안 접근 방식에서 놓칠 수 있는 다른 문제를 처리하는 것을 잊어서는 안 됩니다.
내용