>  기사  >  데이터 베이스  >  MySQL 보안 가이드(1)(리디렉션됨)

MySQL 보안 가이드(1)(리디렉션됨)

黄舟
黄舟원래의
2016-12-17 15:04:03976검색

MySQL 보안 가이드
저자: Yanzi


MySQL 시스템 관리자로서 귀하는 MySQL 데이터베이스 시스템의 데이터 보안과 무결성을 유지할 책임이 있습니다. 이 기사에서는 주로 안전한 MySQL 시스템을 구축하는 방법을 소개하고 시스템의 내부 및 외부 네트워크 관점에서 가이드를 제공합니다.

이 글에서는 주로 다음과 같은 보안 관련 문제를 다룹니다.

보안이 중요한 이유는 무엇이며 어떤 공격에 대비해야 합니까?
서버가 직면하는 위험(내부 보안), 어떻게 대처해야 할까요?
서버 연결에 따른 클라이언트 리스크(외부 보안), 어떻게 대처해야 할까요?
MySQL 관리자는 데이터베이스 시스템의 내부 보안 및 외부 보안과 관련하여 올바르게 권한이 부여된 사용자만 이러한 데이터 레코드에 액세스할 수 있도록 데이터베이스 콘텐츠의 보안을 보장할 책임이 있습니다.
내부 보안은 파일 시스템 수준 문제, 즉 서버 호스트에 계정(합법적이거나 도난당한)을 가진 사람이 MySQL 데이터 디렉터리(DATADIR)를 공격하는 것을 방지하는 것과 관련이 있습니다. 모든 사람이 해당 데이터베이스 테이블에 해당하는 파일을 간단히 무시할 수 있도록 데이터 디렉토리의 내용이 과도하게 부여된 경우 네트워크를 통한 클라이언트 액세스를 제어하는 ​​인증 테이블이 올바르게 설정되었는지 확인하는 것은 의미가 없습니다.

외부 보안은 클라이언트가 네트워크를 통해 외부에서 서버에 연결하는 것과 관련됩니다. 즉, 네트워크를 통해 서버에 연결할 때 발생하는 공격으로부터 MySQL 서버를 보호합니다. MySQL 승인 테이블을 설정해야 합니다(승인 테이블), 유효한 사용자 이름과 비밀번호를 제공하지 않으면 서버 관리 데이터베이스의 콘텐츠에 액세스할 수 없습니다.

다음에서는 MySQL의 2단계 보안을 구현하기 위해 파일 시스템 및 권한 테이블 mysql을 설정하는 방법을 자세히 소개합니다.


1. 내부 보안 - 데이터 디렉토리 접근 보안 보장
MySQL 서버는 MySQL 데이터베이스의 인증 테이블을 통해 유연한 권한 시스템을 제공합니다. 데이터베이스에 대한 클라이언트 액세스를 허용하거나 거부하도록 이러한 테이블의 내용을 설정할 수 있습니다. 이는 승인되지 않은 네트워크 액세스가 데이터베이스를 공격하는 것을 방지하는 보안 조치를 제공합니다. 그러나 호스트의 다른 사용자가 데이터베이스의 내용에 직접 액세스할 수 있습니다. 데이터 디렉터리에 네트워크를 통한 데이터베이스 액세스에 대한 보안을 강화하는 것은 MySQL 서버가 실행 중인 호스트 시스템에 로그인한 유일한 사용자라는 사실을 모르고 다른 사용자의 가능성에 대해 걱정해야 한다는 사실을 알지 않는 한 도움이 되지 않습니다. 이 머신에서 데이터 디렉토리에 대한 액세스 권한을 얻습니다.

보호해야 할 항목은 다음과 같습니다.

데이터베이스 파일. 당연히 서버 관리 데이터베이스의 개인 정보를 유지하고 싶을 것입니다. 데이터베이스 소유자는 일반적으로 원하지 않더라도 데이터베이스 콘텐츠의 보안을 고려해야 하며, 열악한 데이터 디렉터리 보안을 통해 데이터베이스 콘텐츠를 노출하는 대신 데이터베이스 콘텐츠를 공개하는 것을 고려해야 합니다.
로그 파일. 일반 및 변경 로그에는 쿼리 텍스트가 포함되어 있으므로 안전하게 유지되어야 합니다. 로그 파일에 액세스할 수 있는 사람은 누구나 데이터베이스에서 수행되는 작업을 모니터링할 수 있습니다.
더 중요하게 고려해야 할 로그 파일의 보안은 GRANT, SET 등입니다. PASSWord와 같은 쿼리도 기록되며 일반적으로 업데이트 로그에는 비밀번호를 포함한 민감한 쿼리 텍스트가 포함됩니다(MySQL은 비밀번호 암호화를 사용하지만 설정될 때까지 후속 연결 설정에는 사용되지 않습니다. 비밀번호 설정 프로세스는 다음과 같습니다). GRANT나 SET처럼 디자인됨 PASSWORD 및 기타 쿼리는 일반 텍스트로 로그 파일에 기록됩니다. 공격자가 파일에 대한 읽기 액세스 권한을 얻은 경우 로그 파일에서 grep을 실행하여 GRANT 및 PASSWORD와 같은 단어를 찾아 민감한 정보를 발견할 수 있습니다.
분명히 서버 호스트의 다른 사용자에게 데이터베이스 디렉터리 파일에 대한 쓰기 액세스 권한을 부여하고 싶지는 않을 것입니다. 상태 파일이나 데이터베이스 테이블 파일을 덮어쓸 수 있기 때문입니다. 그러나 읽기 액세스도 위험합니다. 데이터베이스 테이블 파일을 읽을 수 있으면 파일을 훔쳐서 MySQL 자체에 접속하여 테이블 내용을 일반 텍스트로 표시하는 것이 번거롭습니다. 이유는 무엇입니까? 다음을 수행해야 하기 때문입니다.

서버 호스트에 자신만의 "특수" MySQL 서버를 설치하세요. 단, 공식 서버 버전과 다른 포트, 소켓 및 데이터 디렉터리를 사용하세요.
mysql_install_db를 실행하여 데이터 디렉터리를 초기화하면 MySQL의 역할이 부여됩니다. 루트 사용자는 서버에 액세스할 수 있으므로 서버 액세스 메커니즘을 완전히 제어할 수 있습니다. 또한 테스트 데이터베이스도 생성됩니다.
도용하려는 테이블에 해당하는 파일을 서버의 데이터베이스 디렉터리 아래 test 디렉터리에 복사합니다.
서버를 시작하세요. 원하는 대로 데이터베이스 테이블에 액세스할 수 있습니다. SHOW TABLES FROM 테스트에서는 도난당한 테이블의 복사본이 있음을 보여주고, SELECT *는 그 중 전체 내용을 보여줍니다.
정말 악의적인 경우 서버의 익명 사용자에게 권한을 노출하여 누구나 어디서나 서버에 연결하고 테스트 데이터베이스에 액세스할 수 있도록 하세요. 이제 도난당한 데이터베이스 테이블을 공개했습니다.
생각해보면 반대의 관점에서 보면 다른 사람들이 당신에게 이런 짓을 해주기를 바라나요? 물론 그렇지 않습니다! ls를 실행하여 데이터베이스에 로그인할 수 있습니다. -l 명령은 데이터베이스에 안전하지 않은 파일과 디렉터리가 포함되어 있는지 확인합니다. "그룹" 및 "기타 사용자" 권한이 설정된 파일과 디렉터리를 찾습니다. 다음은 안전하지 않은 데이터 디렉토리의 일부 목록입니다:

 
% ls -l
총 10148
drwxrwxr-x 11 mysqladm 휠 1024 5월 8일 12:20 .
drwxr-xr-x 22 루트 휠 512 5월 8일 13:31 ..
drwx------ 2 mysqladm mysqlgrp 512 APR 16 15:57 동물원
drwxrwxr-x 2 mysqladm 휠 512 1월 25일 20:40 mysql
drwxrwxr-x 7 mysqladm 휠 512 1998년 8월 31일 sql-bench
drwxrwxr-x 2 mysqladm 휠 1536 5월 6일 06:11 테스트
drwx------ 2 mysqladm mysqlgrp 1024 5월 8일 18:43 tmp
....


보시다시피 일부 데이터베이스에는 올바른 권한이 있지만 다른 데이터베이스에는 그렇지 않습니다. 이 예의 상황은 일정 시간이 지난 후의 결과입니다. 덜 제한적인 권한은 최신 버전보다 권한 설정이 덜 제한적인 이전 서버에 의해 설정됩니다(더 제한적인 디렉터리인 menageria 및 tmp는 모두 더 최근 날짜를 가집니다). 현재 버전의 MySQL은 서버를 실행하는 사용자만 이러한 파일을 읽을 수 있도록 보장합니다.

서버 사용자만 액세스할 수 있도록 권한을 수정하겠습니다. 기본 보호 도구는 파일 및 디렉터리 소유권과 모드를 설정하기 위해 UNIX 파일 시스템 자체에서 제공하는 도구에서 나옵니다. 우리가 해야 할 일은 다음과 같습니다:

디렉토리로 이동
% CD DATADIR

데이터 디렉터리에 있는 모든 파일의 소유권을 서버를 실행하는 데 사용되는 계정이 소유하도록 설정합니다(이 단계를 수행하려면 루트여야 합니다). 본 글에서는 계정의 사용자 이름과 그룹 이름으로 mysqladm과 mysqlgrp를 사용한다. 다음 명령 중 하나를 사용하여 소유자를 변경할 수 있습니다:
# chown mysqladm.mysqlgrp .

# find . -follow -type d -print | mysqladm.mysqlgrp

mysqladm만 읽을 수 있도록 데이터 디렉터리와 데이터베이스 디렉터리의 모드를 설정합니다. 이렇게 하면 다른 사용자가 데이터베이스 디렉터리의 내용에 액세스할 수 없습니다. 다음 명령 중 하나를 사용하여 루트 또는 mysqladm으로 실행할 수 있습니다.
% chmod -R go-rwx .

% find . -follow -type d -print | go-rwx

mysqladm에는 데이터 디렉토리 내용의 소유자와 모드가 설정됩니다. 이제 데이터베이스 디렉토리에 액세스할 수 있는 유일한 사용자(루트 제외)이기 때문에 항상 mysqladm 사용자로 서버를 실행해야 합니다.
이 설정을 완료한 후에는 다음 데이터 디렉터리 권한이 부여되어야 합니다:

% ls -l
total 10148
drwxrwx--- 11 mysqladm mysqlgrp 1024 5월 8일 12:20 .
drwxr-xr-x 22 루트 휠 512 5월 8일 13:31 ..
drwx------ 2 mysqladm mysqlgrp 512 4월 16일 15:57 동물원
drwx------ 2 mysqladm mysqlgrp 512 1월 25일 20:40 mysql
drwx------ 7 mysqladm mysqlgrp 512 1998년 8월 31일 sql-bench
drwx------ 2 mysqladm mysqlgrp 1536 5월 6일 06:11 테스트
drwx------ 2 mysqladm mysqlgrp 1024 5월 8일 18:43 tmp
....



2. 외부 보안 - 네트워크 접속 보안 보장
MySQL의 보안 시스템은 매우 유연하며, 다양한 보안 기능을 사용할 수 있습니다. 사용자 권한을 설정하는 다른 방법. 일반적으로 클라이언트 액세스를 제어하는 ​​권한 부여 테이블을 수정하는 표준 SQL GRANT 및 REVOKE 문을 사용하여 이를 수행할 수 있습니다. 그러나 이를 지원하지 않는 이전 버전의 MySQL(3.22.11 이전)에서는 문제가 발생할 수 있습니다. 작동하지 않음) 또는 사용자 권한이 원하는 방식으로 작동하지 않는 것 같습니다. 이러한 상황에서는 MySQL 인증 테이블의 구조와 서버가 이를 사용하여 액세스 권한을 결정하는 방법을 이해하는 것이 도움이 됩니다. 이러한 이해를 통해 인증 테이블을 직접 수정하여 사용자 권한을 추가, 삭제 또는 수정할 수도 있습니다. 권한 문제를 진단할 때 이러한 테이블을 검사할 수 있습니다.

사용자 계정 관리 방법은 "MySQL 사용자 관리"를 참조하세요. GRANT 및 REVOKE 문에 대한 자세한 설명은 "MySQL 참조 매뉴얼"을 참조하세요.

2.1 MySQL 인증 테이블의 구조와 내용
네트워크를 통해 서버에 연결하는 클라이언트의 MySQL 데이터베이스에 대한 액세스는 인증 테이블의 내용에 따라 제어됩니다. 이 테이블은 mysql 데이터베이스에 있으며 MySQL을 처음 설치할 때(mysql_install_db 스크립트 실행) 초기화됩니다. 5개의 인증 테이블이 있습니다: user, db, host, tables_priv 및 columns_priv.

표 1 사용자, DB, 호스트 권한 테이블 구조
접속 범위 열

사용자 DB 호스트
호스트 호스트 호스트
사용자 DB Db
비밀번호 사용자
데이터베이스/테이블 권한 열
Alter_priv Alter_priv Alter_priv
Create_priv Create_priv Create_priv
Delete_priv Delete_priv Delete_priv
Drop_priv Drop_priv Drop_priv
Index_priv Index_priv Index_priv
Insert_priv Insert_priv Insert_priv
References_priv References_priv References_priv
Select_priv Select_priv Select_priv
Update_priv Update_priv Update_priv
File_priv Grant_priv Grant_priv
Grant_priv 
Process_priv 
Reload_priv 
Shutdown_priv 

테이블 2 tables_priv 및 columns_priv 소유권 테이블 구조

액세스 범위 열
tables_priv columns_priv
호스트 호스트
Db Db
사용자 사용자
테이블_이름 테이블_이름
Column_name
권한 열
Table_priv Column_priv

인증 테이블의 내용은 다음과 같은 목적으로 사용됩니다.

사용자 테이블
사용자 테이블에는 서버에 연결할 수 있는 사용자와 해당 비밀번호가 나열되어 있으며, 어떤 종류의 권한이 있는지 지정합니다. 전역(수퍼유저)에는 권한이 있습니다. 사용자 테이블에 활성화된 모든 권한은 전역 권한이며 모든 데이터베이스에 적용됩니다. 예를 들어 DELETE 권한을 활성화하면 여기에 나열된 사용자는 모든 테이블에서 레코드를 삭제할 수 있으므로 이 작업을 수행하기 전에 신중하게 생각하십시오.
db 테이블
db 테이블은 사용자가 액세스 권한을 가진 데이터베이스를 나열합니다. 여기에 지정된 권한은 데이터베이스의 모든 테이블에 적용됩니다.
호스트 테이블
호스트 테이블은 db 테이블과 결합하여 특정 호스트의 데이터베이스 접근 권한을 더 나은 수준으로 제어하는데, 이는 db만 사용하는 것보다 더 나을 수 있습니다. 이 테이블은 GRANT 및 REVOKE 문의 영향을 받지 않으므로 전혀 사용하지 않는 것을 알 수 있습니다.
tables_priv 테이블
tables_priv 테이블은 테이블 수준 권한을 지정합니다. 여기에 지정된 권한은 테이블의 모든 열에 적용됩니다.
columns_priv 테이블
columns_priv 테이블은 열 수준 권한을 지정합니다. 여기에 지정된 권한은 테이블의 특정 열에 적용됩니다.
"GRANT 없이 사용자 설정" 섹션에서는 GRANT 문이 이러한 테이블을 수정하는 데 어떻게 작동하는지, 그리고 인증 테이블을 직접 수정하여 동일한 효과를 얻을 수 있는 방법에 대해 설명합니다.

MySQL의 tables_priv 및 columns_priv 테이블 버전 3.22.11에서 도입되었습니다(GRANT 문과 동시에). 이전 버전의 MySQL을 사용하는 경우 mysql 데이터베이스에는 사용자, db 및 호스트 테이블만 있습니다. 이전 버전에서 3.22.11 이상으로 업그레이드했고 tables_priv 및 columns_priv 테이블이 없는 경우 mysql_fix_privileges_tables 스크립트를 실행하여 테이블을 생성하세요.

MySQL에는 레코드 수준 권한을 제공하지 않기 때문에rows_priv 테이블이 없습니다. 예를 들어 특정 열 값이 포함된 테이블의 행으로 사용자를 제한할 수 없습니다. 이 기능이 정말로 필요하다면 애플리케이션 프로그래밍을 사용하여 이를 제공해야 합니다. 권장되는 레코드 수준 잠금을 수행하려면 GET_LOCK() 함수를 사용하면 됩니다.

권한 부여 테이블에는 권한 적용 시기를 결정하는 범위 열과 부여되는 권한을 결정하는 권한 열이라는 두 가지 유형의 열이 포함되어 있습니다.

2.1.1 권한 테이블 범위 열
인증 테이블 범위 열은 테이블의 권한이 적용되는 시기를 지정합니다. 각 인증 테이블 항목에는 특정 호스트에서 특정 사용자의 연결에 권한이 적용되는 시기를 지정하는 사용자 및 호스트 열이 포함되어 있습니다. 다른 테이블에는 권한이 적용되는 데이터베이스를 나타내는 Db 열이 포함된 db 테이블과 같은 추가 범위 열이 포함되어 있습니다. 마찬가지로 tables_priv 및 columns_priv 테이블에는 데이터베이스의 특정 테이블이나 테이블의 특정 열로 범위를 좁히는 범위 필드가 포함되어 있습니다.

2.1.2 권한 테이블 권한 열
권한 테이블에는 범위 열에 지정된 사용자가 가지고 있는 권한을 나타내는 권한 열도 포함되어 있습니다. MySQL에서 지원하는 권한은 다음 표에 나와 있습니다. 테이블은 GRANT 문의 권한 이름을 사용합니다. 사용자, db 및 호스트 테이블에 있는 대부분의 권한 열 이름의 경우 GRANT 문의 이름 사이에는 분명한 연결이 있습니다. 예를 들어 Select_priv는 SELECT 권한에 해당합니다.

위 내용은 MySQL 보안 가이드(1)(재게시) 내용입니다. 더 많은 관련 글은 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요!


성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
이전 기사:전문검색 활용(3)다음 기사:전문검색 활용(3)