원격 접근 보안 모범 사례

SSH 포트가 열려 있는 모든 서버는 지금 이 순간에도 공격받고 있습니다. 공격받을 수도 있다는 게 아닙니다. 지금 공격받고 있습니다.

자동화된 스캐너들이 인터넷 전체를 끊임없이 돌아다니며 모든 IP 주소의 원격 접근 포트를 탐색합니다. 열린 포트를 발견하면 즉시 무차별 대입 공격이 시작됩니다—몇 분 안에 수천 가지 아이디와 비밀번호 조합을 시도합니다. 이때 쓰는 자격 증명은 무작위가 아닙니다. 데이터 유출 사고에서 수집되고, 흔히 쓰이는 기본값들을 정리하고, 수년간의 성공적인 침입을 통해 다듬어진 것들입니다.

이건 가상의 이야기가 아닙니다. 인터넷에 연결된 서버의 인증 로그를 확인해 보세요. 전 세계 IP 주소에서 root, admin, ubuntu, deploy 같은 계정명과 password, 123456, admin 같은 비밀번호로 로그인에 실패한 기록을 볼 수 있을 겁니다. 몇 초마다. 끊임없이.

원격 접근 보안은 언젠가 일어날지 모르는 이론적인 공격을 막는 것이 아닙니다. 지금 이 순간에도—쉼 없이—진행되는 공격들이 계속 실패하도록 만드는 것입니다.

세 가지 방어선

원격 접근 보안을 세 개의 동심원형 방어선으로 생각해 보세요.

1. 공격자가 문 앞까지 올 수 있는가? 공격자가 연결을 시도조차 할 수 있는지를 결정하는 네트워크 수준의 통제.

2. 공격자가 문을 열 수 있는가? 접근을 허용하기 전에 신원을 확인하는 인증.

3. 들어온 후 무엇을 할 수 있는가? 인증된 사용자가 접근할 수 있는 것을 제한하는 권한 부여.

강력한 보안은 세 가지 모두를 갖춰야 합니다. 어느 한 방어선의 취약점이 그 뒤의 모든 것을 위협할 수 있습니다.

첫 번째 방어선: 접근 차단

가장 효과적인 보안 조치는 문 자체를 보이지 않게 만드는 것입니다.

원격 접근을 인터넷에 노출하지 마세요. 인터넷에 직접 연결될 필요가 없는 서버라면 아예 그 경로를 만들지 마세요. 사설 네트워크(10.x.x.x, 172.16.x.x, 192.168.x.x)에 두어 외부에서 접근하지 못하도록 하고, SSH나 RDP 시도 전에 VPN 연결을 요구하세요. VPN에 먼저 인증하지 않은 사람에게는 공격 표면이 아예 존재하지 않습니다.

인터넷 접근이 꼭 필요하다면 배스천 호스트를 사용하세요. 단 하나의 강화된 서버가 인터넷에서 오는 원격 연결을 받습니다. 나머지 서버들은 모두 이 배스천을 통해서만 접근할 수 있습니다. 이제 오십 개의 문이 아닌 단 하나의 문만 지키면 됩니다.

IP 주소로 방화벽을 설정하세요. 팀이 고정 IP를 가진 알려진 위치에서 작업한다면, 그 주소에서만 SSH 연결을 허용하도록 방화벽을 구성하세요. 공격자는 닿을 수 없는 곳을 무차별 대입할 수 없습니다.

기본 포트 변경(SSH를 22번 포트에서 다른 번호로 이동)은 진정한 보안이 아닙니다—특정 서버를 대상으로 스캔하는 사람은 금방 새 포트를 찾아낼 것입니다. 그러나 잡음을 줄여주는 효과는 있습니다. 22번 포트를 노리는 자동화 스캐너들이 서비스를 발견하지 못하면, 로그 항목이 줄어들고 불필요한 연결을 거부하는 데 소모되는 리소스도 줄어듭니다.

두 번째 방어선: 인증 강화

공격자가 원격 접근 서비스에 닿았다면, 인증이 그 자리를 굳건히 지켜야 합니다.

SSH 키가 비밀번호를 대체합니다. 이것은 권고 사항이 아니라 기본 요건입니다. 비밀번호는 추측되고, 도난당하고, 피싱될 수 있습니다. SSH 키는 암호학적으로 강력합니다. 개인 키는 절대 내 컴퓨터를 떠나지 않으며, 네트워크를 통해 전송되지 않습니다. 키 배포가 완료되면 비밀번호 인증을 완전히 비활성화하세요.

ssh-keygen -t ed25519 -C "your_email@example.com"

Ed25519는 현대적이고 빠르며 안전합니다. RSA 호환성이 필요한 시스템에서는 최소 4096비트 키를 사용하세요.

개인 키를 패스프레이즈로 보호하세요. 누군가 키 파일을 훔쳐도 패스프레이즈가 마지막 방어선이 됩니다. 패스프레이즈 없이는 키를 쓸 수 없습니다.

민감한 시스템에는 다중 인증을 추가하세요. 자격 증명이 탈취되더라도—피싱은 언제든 일어날 수 있고, 노트북은 도난당합니다—두 번째 인증 요소 없이는 공격자가 더 이상 진행할 수 없습니다. YubiKey 같은 하드웨어 보안 키가 가장 강력하며, SMS나 앱 기반 인증 코드를 뚫는 피싱 공격에도 저항력이 있습니다.

root 로그인을 비활성화하세요. 관리자는 개인 계정으로 접속하고 sudo로 권한을 높입니다. 이렇게 하면 책임 추적이 가능하고(로그에 누가 무엇을 했는지 기록됨), 피해 범위도 제한됩니다(탈취된 사용자 자격 증명이 즉시 전체 시스템 접근으로 이어지지 않음).

인증서 기반 인증은 대규모 환경에서의 키 배포 문제를 해결합니다. 인증 기관이 단기 유효 인증서를 발급하면 서버가 자동으로 신뢰합니다. 수백 개의 서버에 걸쳐 authorized_keys 파일을 일일이 관리할 필요가 없어집니다. 인증서는 자동으로 만료되므로—수년간 방치된 채 남아 있는 잊힌 키도 없습니다.

세 번째 방어선: 내부 권한 제한

인증은 누구인지를 확인합니다. 권한 부여는 무엇을 할 수 있는지를 결정합니다.

최소 권한 원칙: 필요한 접근 권한만 정확히 부여하고 그 이상은 주지 마세요. 데이터베이스 관리자는 데이터베이스에 접근합니다. 웹 개발자는 웹 서버에 접근합니다. "혹시 모르니까"라는 이유로 모든 것에 접근할 수 있는 사람은 없어야 합니다.

적시 접근이 영구 권한보다 낫습니다. 사용자가 특정 시간과 목적에 한정된 상위 권한을 요청합니다. 요청이 승인되면 권한이 부여되고 사용된 뒤 자동으로 회수됩니다. 시간이 지날수록 권한이 쌓여가는 일이 없습니다.

접근 권한을 정기적으로 검토하세요. 사람들의 역할은 바뀝니다. 조직을 떠나는 사람도 생깁니다. 그에 맞게 접근 권한도 바뀌어야 합니다. 분기별 검토를 통해 마케팅 팀으로 이동했지만 여전히 운영 환경 SSH 접근 권한을 가진 개발자를 발견할 수 있습니다.

전송 구간 암호화

강력한 암호화는 공격자가 트래픽을 들여다볼 수 있더라도 내용을 가로채지 못하도록 막아줍니다.

최신 프로토콜 버전을 사용하세요. SSHv1에는 알려진 취약점이 있으므로 모든 시스템에서 비활성화해야 합니다. RDP의 경우 네트워크 수준 인증을 활성화하고 TLS를 요구하세요.

강력한 암호화 알고리즘을 구성하세요. sshd_config에서 취약한 알고리즘을 비활성화하세요.

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
KexAlgorithms curve25519-sha256,diffie-hellman-group-exchange-sha256

호스트 키를 검증하세요. 처음 SSH 연결 시 나타나는 지문(fingerprint) 확인 메시지는 형식적인 절차가 아닙니다—중간자 공격을 막기 위한 보호 수단입니다. 호스트 키가 예상치 않게 바뀌었다면 무언가 잘못된 것입니다. 연결하기 전에 반드시 원인을 파악하세요.

접근 현황 감시

가시성 없는 보안은 증거 없는 희망에 불과합니다.

모든 것을 기록하세요: 인증 시도(성공과 실패 모두), 세션 시간, 출발지 IP, 실행된 명령어. 공격자가 삭제하기 위해 접근할 수 없는 중앙 시스템으로 로그를 전송하세요.

패턴을 모니터링하세요: 한 IP에서 반복되는 실패, 비정상적인 위치에서의 로그인, 이상한 시간대의 접근, 권한 상승 시도. 자동화된 알림이 진행 중인 공격을 포착합니다.

로그를 정기적으로 검토하세요. 자동화된 모니터링은 눈에 띄는 공격을 잡아냅니다. 느리게 진행되는 침입과 알고리즘이 놓치는 내부자 악용은 사람이 직접 로그를 살펴봐야 발견할 수 있습니다.

최신 상태 유지

원격 접근 소프트웨어에는 취약점이 있습니다. 업데이트가 이를 수정합니다.

가능하면 자동 보안 업데이트를 활성화하세요. 많은 Linux 배포판이 중요 패치를 자동으로 설치합니다.

신속하게 패치하세요. 치명적인 SSH나 RDP 취약점 소식을 접했다면, 공격자들이 이를 자동화 도구에 탑재하기까지 몇 주가 아닌 며칠밖에 없습니다.

무엇을 운영하고 있는지 파악하세요. 존재를 잊은 시스템은 패치할 수 없습니다. 원격 접근 엔드포인트를 목록으로 관리하세요.

불편한 진실

완벽한 보안은 존재하지 않습니다. 여기서 소개한 모든 조치는 위험을 줄일 뿐, 어느 것도 위험을 완전히 없애지는 못합니다. 심층 방어란, 어느 한 방어선이 무너졌을 때—언젠가는 반드시 그런 일이 생깁니다—다른 방어선이 버텨준다는 것입니다.

공격은 지금 이 순간에도 일어나고 있습니다. 당신의 보안이 시험대에 오를 것인지가 문제가 아닙니다. 그 시험을 통과할 것인지가 문제입니다.

원격 접근 보안에 관해 자주 묻는 질문

SSH 포트를 22번에서 바꾸는 것이 실제로 효과가 있나요?

보안이라고 할 수 없습니다—당신을 특정해서 노리는 사람이라면 새 포트를 몇 초 만에 찾아낼 것입니다. 그러나 자동화된 잡음을 크게 줄여주는 효과는 있습니다. 대부분의 봇넷은 22번 포트만 확인합니다. 비표준 포트로 옮기면 로그가 깔끔해지고 불필요한 연결을 거부하는 데 낭비되는 리소스가 줄어듭니다. 보안이 아니라 운영 편의를 위해 하세요.

지금 내 서버가 공격받고 있는지 어떻게 확인할 수 있나요?

인증 로그를 확인하세요. Linux에서: grep "Failed password" /var/log/auth.log 또는 journalctl -u sshd | grep "Failed". 낯선 IP 주소에서의 시도를 거의 확실하게 볼 수 있을 겁니다. 이것은 인터넷에 연결된 모든 서버에서 일어나는 정상적인 현상입니다—중요한 것은 당신의 보안 조치가 이를 막고 있는지 여부입니다.

혼자만 서버에 접근한다면 비밀번호 인증을 비활성화해야 하나요?

네. 나 자신으로부터 보호하려는 것이 아닙니다—서버에 비밀번호로 로그인을 시도하는 수천 개의 자동화 공격으로부터 보호하려는 것입니다. 키 전용 인증을 사용하면 그 공격들은 반드시 실패합니다. 비밀번호 인증을 허용하면 각 시도가 성공할 가능성이 아무리 낮더라도 완전히 사라지지 않습니다.

개인 서버를 위해 최소한 무엇을 해야 하나요?

SSH 키만 사용(비밀번호 인증 비활성화), root 계정 직접 로그인 차단, 가능하다면 내 IP로만 방화벽 제한, 자동 보안 업데이트 활성화. 설정하는 데 30분이면 충분하고, 대부분의 공격을 막을 수 있습니다.