데브러너 (DevRunner)

8.1.3 Making MySQL Secure Against Attackers

MySQL 서버에 연결할 때는 비밀번호를 사용해야 합니다.
비밀번호는 연결을 통해 평문으로 전송되지 않습니다.

그 밖의 모든 정보는 텍스트로 전송되며, 연결을 감시할 수 있는 사람이라면 누구나 이 정보를 읽을 수 있습니다. 클라이언트와 서버 사이의 연결이 신뢰할 수 없는 네트워크를 통과하고, 이에 대해 우려가 있다면, 압축 프로토콜을 사용하여 트래픽을 훨씬 더 해독하기 어렵게 만들 수 있습니다. 또한 MySQL의 내부 SSL 지원을 사용하여 연결을 더욱 안전하게 만들 수 있습니다. 자세한 내용은 Section 8.3, “Using Encrypted Connections”을 참조하십시오. 또는 SSH를 사용하여 MySQL 서버와 MySQL 클라이언트 사이에 암호화된 TCP/IP 연결을 얻을 수도 있습니다. 오픈 소스 SSH 클라이언트는 http://www.openssh.org/에서 찾을 수 있으며, 오픈 소스 및 상용 SSH 클라이언트의 비교는 http://en.wikipedia.org/wiki/Comparison_of_SSH_clients에서 확인할 수 있습니다.

MySQL 시스템을 안전하게 만들기 위해서는 다음의 제안들을 강력히 고려해야 합니다:

모든 MySQL 계정이 비밀번호를 갖도록 요구하십시오. 클라이언트 프로그램은 프로그램을 실행하는 사람의 신원을 반드시 알고 있는 것은 아닙니다. 클라이언트/서버 애플리케이션에서는 사용자가 클라이언트 프로그램에 임의의 사용자 이름을 지정할 수 있는 것이 일반적입니다. 예를 들어, mysql 프로그램을 mysql -u other_user db_name과 같이 실행하면, _other_user_에 비밀번호가 없는 경우 누구든지 다른 사람으로서 접속할 수 있습니다. 모든 계정에 비밀번호가 있다면, 다른 사용자의 계정을 사용해 접속하는 것은 훨씬 더 어려워집니다.

비밀번호 설정 방법에 대한 논의는 Section 8.2.14, “Assigning Account Passwords”를 참조하십시오.
데이터베이스 디렉터리에서 읽기 또는 쓰기 권한을 가진 유일한 유닉스 사용자 계정이 mysqld를 실행하는 데 사용되는 계정인지 확인하십시오.
MySQL 서버를 유닉스 root 사용자로 실행하지 마십시오. 이는 매우 위험합니다. FILE 권한을 가진 사용자는 서버로 하여금 root 권한으로 파일을 생성하게 할 수 있기 때문입니다(예: ~root/.bashrc). 이를 방지하기 위해 mysqld는 --user=root 옵션을 사용해 명시적으로 지정하지 않는 한 root로 실행되는 것을 거부합니다.

mysqld는 일반적인, 권한이 없는(unprivileged) 사용자로 실행할 수 있고, 그렇게 해야 합니다. 별도의 유닉스 계정 mysql을 만들어 보안을 한층 강화할 수 있습니다. 이 계정은 MySQL 관리에만 사용하십시오. 다른 유닉스 사용자로 mysqld를 시작하려면 서버 옵션을 지정하는 my.cnf 옵션 파일의 [mysqld] 그룹에 사용자 이름을 지정하는 user 옵션을 추가하십시오. 예를 들면 다음과 같습니다:
```
1[mysqld]
2user=mysql
```
이렇게 하면 mysqld_safe 또는 mysql.server를 사용하든, 수동으로 시작하든, 지정된 사용자로 서버가 시작됩니다. 자세한 내용은 Section 8.1.5, “How to Run MySQL as a Normal User”를 참조하십시오.

mysqld를 root가 아닌 다른 유닉스 사용자로 실행한다고 해서 user 테이블의 root 사용자 이름을 변경해야 한다는 뜻은 아닙니다. MySQL 계정의 사용자 이름은 유닉스 계정의 사용자 이름과 아무 관련이 없습니다.
비관리자(nonadministrative) 사용자에게 FILE 권한을 부여하지 마십시오. 이 권한을 가진 사용자는 파일 시스템 어디든지 mysqld 데몬의 권한으로 파일을 쓸 수 있습니다. 여기에는 권한 테이블을 구현하는 파일이 있는 서버의 데이터 디렉터리도 포함됩니다. FILE 권한을 사용하는 작업을 조금 더 안전하게 하기 위해, SELECT ... INTO OUTFILE로 생성된 파일은 기존 파일을 덮어쓰지 않으며, 모든 사용자가 쓰기할 수 있습니다.

FILE 권한은 모든 사용자가 읽을 수 있거나 서버를 실행하는 유닉스 사용자가 액세스 가능한 모든 파일을 읽는 데에도 사용할 수 있습니다. 이 권한이 있으면 임의의 파일을 데이터베이스 테이블로 읽어 올 수 있습니다. 예를 들어 LOAD DATA를 사용해 /etc/passwd를 테이블로 로드한 다음, 이를 SELECT로 표시하는 방식으로 악용될 수 있습니다.

파일을 읽고 쓸 수 있는 위치를 제한하려면 secure_file_priv 시스템을 특정 디렉터리로 설정하십시오. 자세한 내용은 Section 7.1.8, “Server System Variables”를 참조하십시오.
바이너리 로그 파일과 릴레이 로그 파일을 암호화하십시오. 암호화는 이러한 파일과 그 안에 포함될 수 있는 민감한 데이터가 외부 공격자에 의해 악용되거나, 파일이 저장된 운영체제의 사용자에 의해 무단으로 열람되는 것을 방지하는 데 도움이 됩니다. MySQL 서버에서 암호화를 활성화하려면 binlog_encryption 시스템 변수를 ON으로 설정하십시오. 자세한 내용은 Section 19.3.2, “Encrypting Binary Log Files and Relay Log Files”를 참조하십시오.
비관리자 사용자에게 PROCESS 또는 SUPER 권한을 부여하지 마십시오. mysqladmin processlist와 SHOW PROCESSLIST의 출력에는 현재 실행 중인 문장의 텍스트가 표시되므로, 서버 프로세스 리스트를 볼 수 있는 사용자는 다른 사용자가 실행한 문장을 볼 수 있을지도 모릅니다.

mysqld는 CONNECTION_ADMIN 또는 SUPER 권한을 가진 사용자를 위해 하나의 추가 연결을 예약해 둡니다. 따라서 모든 일반 연결이 사용 중이더라도 MySQL root 사용자가 로그인하여 서버 활동을 확인할 수 있습니다.

SUPER 권한은 클라이언트 연결을 종료하고, 시스템 변수 값을 변경하여 서버 동작을 변경하며, 복제 서버를 제어하는 데 사용할 수 있습니다.
테이블에 대한 심볼릭 링크 사용을 허용하지 마십시오. (이 기능은 --skip-symbolic-links 옵션으로 비활성화할 수 있습니다.) 특히 mysqld를 root로 실행하는 경우 매우 중요합니다. 이 때 서버의 데이터 디렉터리에 쓰기 액세스를 가진 누구든지 시스템의 임의의 파일을 삭제할 수 있기 때문입니다! 자세한 내용은 Section 10.12.2.2, “Using Symbolic Links for MyISAM Tables on Unix”를 참조하십시오.
저장 프로그램과 뷰는 Section 27.8, “Stored Object Access Control”에서 논의된 보안 지침을 사용하여 작성해야 합니다.
DNS를 신뢰하지 않는다면 그랜트 테이블에서 호스트 이름 대신 IP 주소를 사용해야 합니다. 어떤 경우든지, 와일드카드를 포함하는 호스트 이름 값을 사용하여 그랜트 테이블 엔트리를 생성할 때에는 매우 주의해야 합니다.
단일 계정에 허용되는 연결 수를 제한하려면 mysqld에서 max_user_connections 변수를 설정하면 됩니다. CREATE USER 및 ALTER USER 문 역시 계정에 허용되는 서버 사용 범위를 제한하기 위한 리소스 제어 옵션을 지원합니다. Section 15.7.1.3, “CREATE USER Statement”와 Section 15.7.1.1, “ALTER USER Statement”를 참조하십시오.
플러그인 디렉터리가 서버에 의해 쓰기 가능하다면, 사용자가 SELECT ... INTO DUMPFILE를 사용하여 해당 디렉터리에 실행 가능한 코드를 파일로 기록할 수 있을지도 모릅니다. 이는 plugin_dir을 서버에 대해 읽기 전용으로 만들거나, SELECT 쓰기를 안전하게 수행할 수 있는 디렉터리로 secure_file_priv를 설정함으로써 방지할 수 있습니다.