업데이트됨 1개월 전
웹 애플리케이션이 비밀번호를 확인할 때, 데이터베이스에 묻습니다. 장바구니를 불러오거나, 프로필을 표시하거나, 거래를 기록할 때도—데이터베이스입니다. 그 요청은 MySQL의 기본 관문인 포트 3306을 통해 이루어집니다.
이 일은 끊임없이 일어납니다. 가끔이 아니라, 사용자가 버튼을 클릭할 때만이 아니라—끊임없이. 백그라운드 작업, 상태 확인, 세션 검증, 캐시 웜업. 애플리케이션은 데이터베이스와 마치 숨을 쉬듯 대화합니다: 자동으로, 지속적으로, 의식하지 않고. 포트 3306이 그 모든 것을 운반합니다.
포트 3306에서 일어나는 일
MySQL은 관계형 데이터베이스 관리 시스템입니다. 데이터를 테이블에 저장하고, SQL로 작성된 쿼리를 받아 결과를 반환합니다. MySQL 서버가 시작되면 포트 3306에서 클라이언트—애플리케이션 코드, 커맨드라인 도구, 분석 플랫폼—의 연결을 기다립니다.
클라이언트가 연결되면 자격증명으로 신원을 증명하고, 그 다음 지속적인 TCP 연결을 통해 SQL 쿼리를 보내고 결과를 받습니다. 연결은 열린 상태를 유지하여, 쿼리마다 재연결하는 오버헤드 없이 빠른 통신이 가능합니다.
애플리케이션이 실행하는 모든 쿼리—"이 사용자가 존재하는가?", "장바구니에 무엇이 있는가?", "이 구매를 기록하라"—는 포트 3306을 통해 전달됩니다.
로컬 연결 vs. 원격 연결
애플리케이션이 MySQL과 통신하는 방식은 두 가지 구성이 주를 이룹니다.
로컬 연결은 애플리케이션과 데이터베이스가 같은 머신에서 실행될 때 발생합니다. 개발 서버를 실행 중인 노트북은 포트 3306의 localhost를 통해 MySQL에 연결합니다. 데이터는 네트워크 케이블에 닿지 않습니다. 운영 체제의 보호 아래 머신 내부에 머뭅니다. 외부로 나가지 않으니 누구도 가로챌 수 없습니다.
원격 연결은 데이터베이스가 다른 서버에 있을 때 발생합니다. 프로덕션 환경에서는 이것이 일반적입니다: 웹 서버는 한 곳에, 데이터베이스 서버는 다른 곳에. 이제 연결은 네트워크를 통해 이동합니다—데이터 센터의 사설 네트워크, 클라우드 VPC, 또는 공용 인터넷.
보안 함의는 완전히 다릅니다. 로컬 연결은 본질적으로 보호됩니다. 원격 연결은 의도적인 보호가 필요합니다.
포트 3306을 노출하는 것이 위험한 이유
공격자들이 포트 3306을 스캔하는 것은 스키마가 궁금해서가 아닙니다. 데이터베이스에는 훔칠 만한 것들이 있기 때문입니다: 자격증명, 결제 정보, 개인 데이터, 비즈니스 기밀. 노출된 MySQL 포트는 모든 것을 가져가라는 초대입니다.
자동화된 도구들은 인터넷 전체를 스캔하여 열린 포트 3306 인스턴스를 찾습니다. 하나를 발견하면 root, admin, mysql 같은 일반적인 사용자 이름으로 수천 가지 비밀번호 조합을 시도합니다. 패치되지 않은 취약점을 탐색하고, 변경되지 않은 기본 자격증명을 찾습니다.
강력한 비밀번호도 위험을 완전히 없애지는 못합니다. MySQL의 제로데이 취약점은 패치하기 전에 공격자에게 접근 권한을 줄 수 있습니다. 암호화되지 않은 연결은 네트워크 경로상의 누구든 쿼리와 결과를 읽을 수 있게 합니다. 공격 표면이 너무 넓습니다.
규칙은 절대적입니다: MySQL은 공용 인터넷에서 직접 접근 가능해서는 안 됩니다.
포트 3306을 보호하는 방법
네트워크 방화벽이 첫 번째 장벽입니다. 포트 3306의 연결을 특정 IP 주소—웹 서버, 관리자 머신—에서만 허용하도록 방화벽을 구성하세요. 클라우드 플랫폼은 이를 쉽게 만듭니다. AWS 보안 그룹은 RDS 인스턴스가 특정 보안 그룹의 EC2 인스턴스에서만 연결을 받도록 제한할 수 있습니다. 나머지는 아무것도 얻지 못합니다.
MySQL 자체 접근 제어가 두 번째 레이어를 추가합니다. 데이터베이스 사용자를 생성할 때 해당 사용자가 어느 호스트에서 연결할 수 있는지 지정합니다. webapp@192.168.1.100으로 정의된 사용자는 정확히 그 IP 주소에서만 인증할 수 있습니다. 공격자가 비밀번호를 훔쳐도 다른 곳에서는 사용할 수 없습니다.
이 레이어들은 함께 작동합니다. 공격자는 인가된 서버를 장악하고 해당 특정 호스트의 유효한 자격증명을 얻어야 합니다. 둘 중 하나만으로는 소용없습니다.
데이터베이스 트래픽 암호화
방화벽은 인가되지 않은 연결을 차단합니다. 그렇다면 인가된 연결은 어떨까요? 웹 서버가 네트워크를 통해 데이터베이스에 쿼리할 때, 그 트래픽에는 자격증명, SQL 쿼리, 결과 집합이 담겨 있습니다. 암호화가 없으면 네트워크를 관찰할 수 있는 누구든 모든 것을 읽을 수 있습니다.
MySQL은 연결을 위한 TLS 암호화를 지원합니다. 활성화되면 클라이언트와 서버는 핸드셰이크 중에 암호화된 채널을 설정합니다. 그 이후의 모든 것—인증, 쿼리, 결과—은 암호화된 터널을 통해 이동합니다.
서버 레벨(모든 연결은 암호화 필수) 또는 사용자 레벨(특정 사용자는 암호화 필수)에서 TLS를 요구할 수 있습니다. 현대적 관행은 모든 곳에서 요구하는 것입니다. 커넥션 풀링과 현대 하드웨어를 사용하면 성능 비용은 최소화됩니다1. 보호 효과는 상당합니다.
Amazon RDS와 같은 관리형 데이터베이스 서비스는 기본적으로 TLS를 활성화하고 인증서를 자동으로 제공합니다. 사용하지 않을 이유가 없습니다.
올바른 연결 문자열
애플리케이션은 연결 문자열로 MySQL에 연결합니다:
자격증명을 코드에 직접 넣지 마세요. 버전 관리에 커밋하지 마세요. 환경 변수, HashiCorp Vault나 AWS Secrets Manager 같은 비밀 정보 관리 도구, 또는 제한된 권한을 가진 설정 파일에 저장하세요. git 저장소의 자격증명은 곧 인터넷에 공개된 자격증명입니다.
포트를 명시적으로 포함하면(3306이 기본값이더라도) 설정이 더 명확해지고 필요시 다른 포트에서 MySQL을 실행할 수 있습니다. 하지만 포트를 변경하는 것은 보안 조치가 아닙니다—그저 눈속임에 불과합니다. 공격자들은 3306만이 아니라 모든 포트를 스캔합니다.
전체 그림
MySQL 보안은 계층적입니다. 각 계층은 서로 다른 위협을 다룹니다:
- 네트워크 격리는 인가되지 않은 연결이 시작되기 전에 차단합니다
- 호스트 기반 접근 제어는 어떤 머신이 어떤 사용자로 인증할 수 있는지 제한합니다
- 강력한 자격증명은 무차별 대입 공격을 어렵게 만듭니다
- TLS 암호화는 전송 중인 데이터를 도청으로부터 보호합니다
- 비밀 정보 관리는 자격증명이 코드와 로그 밖에 있도록 합니다
단일 계층으로는 충분하지 않습니다. 하지만 함께라면, 데이터베이스를 튼튼히 지킬 수 있습니다.
포트 3306은 숫자에 불과합니다—MySQL의 기본 문입니다. 중요한 것은 그 문을 세상에 열어두었는지 여부입니다. 데이터베이스에는 애플리케이션이 아는 모든 것이 담겨 있습니다. 모든 사용자. 모든 거래. 모든 비밀. 그에 걸맞게 보호하세요.
포트 3306에 관한 자주 묻는 질문
MySQL에 포트 3306을 사용하는 것이 안전한가요?
포트 번호 자체가 보안 문제가 아닙니다—노출이 문제입니다. 인가된 IP 주소만 허용하도록 적절히 구성된 방화벽 뒤에서 포트 3306으로 MySQL을 실행하는 것은 안전합니다. 어떤 포트에서든 공용 인터넷 접근을 허용하는 것은 위험합니다.
MySQL 포트가 인터넷에 노출되어 있는지 어떻게 알 수 있나요?
네트워크 외부에서 연결을 시도해 보세요: mysql -h your-public-ip -P 3306. 어떤 응답이라도 오면(인증 실패라도), 포트는 노출된 것입니다. 온라인 포트 스캐너를 사용할 수도 있습니다. 인터넷에서 접근할 수 있다면, 공격자도 마찬가지입니다.
MySQL을 포트 3306에서 다른 포트로 변경해야 하나요?
포트 변경은 보안 효과가 거의 없습니다. 공격자들은 일반적인 포트만이 아니라 모든 포트를 검사하는 포트 스캐너를 사용합니다. 방화벽 규칙, 접근 제어, 암호화에 집중하세요—이것들이 실제로 공격을 막습니다. 포트를 바꾸는 것은 발견을 몇 초 늦출 뿐입니다.
데이터베이스가 사설 네트워크에 있어도 TLS 암호화가 필요한가요?
그렇습니다. 사설 네트워크가 본질적으로 안전한 것은 아닙니다—같은 네트워크에서 침해된 서버가 트래픽을 엿볼 수 있습니다. TLS 암호화는 현대 하드웨어에서 성능에 거의 영향을 미치지 않으며, 네트워크 수준 공격, 내부자 위협, 잘못 구성된 라우팅으로부터 보호합니다. 모든 곳에서 활성화하세요.
출처
이 페이지가 도움이 되었나요?