MySQL 5.6 한글메뉴얼

18.5.11.2 MySQL Cluster와 MySQL 권한

이 섹션에서는 MySQL Cluster 관련 MySQL 권한 시스템의 구조 및 MySQL Cluster의 보안을 유지하기 위해이 관계에 대해 설명합니다.

MySQL Cluster의 테이블에는 표준 MySQL 권한이 적용됩니다. 여기에는 데이터베이스, 테이블 및 컬럼 수준에서 부여되는 모든 MySQL 권한 유형 ( SELECT 권한 UPDATE 권한 DELETE 권한 등)가 포함됩니다. 기타 MySQL 서버의 경우와 마찬가지로, 사용자 및 권한 정보는 mysql 시스템 데이터베이스에 저장됩니다. NDB 테이블이 같은 테이블이 포함 된 데이터베이스 및 이러한 테이블의 컬럼에 대한 권한을 부여하고 취소하는 데 사용되는 SQL 문 (기타) MySQL 스토리지 엔진을 포함하는 데이터베이스 객체와의 연결에 사용 되는 GRANT 및 REVOKE 문 및 모든 점에서 동일합니다. CREATE USER 및 DROP USER 문에 대해서도 마찬가지입니다.

MySQL 부여 테이블은 기본적으로 MyISAM 스토리지 엔진을 사용하는 것에 유의하는 것이 중요합니다. 따라서 MySQL Cluster의 SQL 노드로 동작하는 MySQL 서버간에 일반적으로 이러한 테이블의 복제와 공유되지 않습니다. 즉, 기본적으로 사용자 및 그들의 권한을 변경해도 자동으로 SQL 노드에 반영되지 않습니다. 필요에 따라 MySQL Cluster의 SQL 노드간에 MySQL 사용자 및 권한의 자동 배포를 활성화 할 수 있습니다. 자세한 내용은 섹션 18.5.14 "MySQL Cluster 배포 된 MySQL 권한" 을 참조하십시오.

반대로, MySQL은 권한을 거부하는 방법이 없기 때문에 (원래 권한을 취소하거나 부여하지 않을 수 있지만 그 자체를 거부 할 수 없습니다) 한 SQL 노드의 NDB 테이블을 다른 SQL 노드에 대한 권한이있는 사용자로부터 보호하는 특별한 방법이 없습니다. 이는 사용자 권한의 자동 배포를 사용하지 않는 경우에도 마찬가지입니다. 이를 보여주는 명확한 예를 들어, 모든 데이터베이스 오브젝트에 대해 어떤 조치를 수행 할 수있는 MySQL의 root 계정이 포함됩니다. 이 계정을 config.ini 파일의 빈 [mysqld] 또는 [api] 섹션과 결합하여 현저하게 위험해질 수 있습니다. 그 이유를 이해하기 위해 다음과 같은 시나리오를 고려합니다.

config.ini 파일에는 적어도 하나의 하늘의 [mysqld] 또는 [api] 섹션이 포함되어 있습니다. 즉, MySQL Cluster 관리 서버에서 MySQL 서버 (또는 다른 API 노드)에서 MySQL Cluster에 액세스 한 호스트 검사가 수행되지 않습니다.
방화벽이 존재하지 않거나 방화벽이 네트워크 외부에있는 호스트에서 MySQL Cluster에 액세스로부터 보호하는 데 실패합니다.
MySQL Cluster 관리 서버의 호스트 이름 또는 IP 주소가 이미 알려져 있거나 네트워크 외부에서 확인할 수 있습니다.

이러한 조건에 해당하는 경우에는 누구든지 어디서나 --ndbcluster --ndb-connectstring= management_host 으로 MySQL Server를 시작하고이 MySQL Cluster에 액세스 할 수 있습니다. MySQL root 계정을 사용하면이 사용자는 다음 작업을 수행 할 수 있습니다.

SHOW DATABASES 명령문 (서버에서 모든 NDB 데이터베이스의 목록을 얻을) 또는 SHOW TABLES FROM some_ndb_database 문 등의 메타 데이터 문을 실행하여 특정 데이터베이스의 모든 NDB 테이블의 목록을 가져옵니다.
검출 된 테이블 중 하나에 대해 다음과 같은 정당한 MySQL 문을 실행합니다.
- 모든 테이블에서 모든 데이터를 읽을 SELECT * FROM some_table
- 테이블에서 모든 데이터를 삭제하는 DELETE FROM some_table
- 테이블 스키마를 확인하는 DESCRIBE some_table 또는 SHOW CREATE TABLE some_table
- 테이블 컬럼에 "부정"데이터를 입력하는 UPDATE some_table SET column1 = some_value . 이 사실은 단순히 모든 데이터를 삭제하는 것보다 훨씬 더 큰 손해가 발생할 수 있습니다
  
  더 교활 형태로는 다음과 같은 문이 포함될 수 있습니다.
```
UPDATE some_table SET an_int_column = an_int_column + 1
```
  또는
```
UPDATE some_table SET a_varchar_column = REVERSE(a_varchar_column)
```
  이러한 악성 문은 공격자의 상상력에서만 제한되지 않습니다.
이런 종류의 공격을받을 우려가없는 유일한 테이블은 NDB 이외의 스토리지 엔진을 사용하여 만들어지고이를 위해 "잘못된"SQL 노드에서 보이지 않는 테이블입니다.

또한 root 로 로그인 할 수있는 사용자는 INFORMATION_SCHEMA 데이터베이스 및 테이블에 액세스 할 수 있기 때문에 데이터베이스, 테이블, 스토어드 루틴 예약 된 이벤트 및 메타 데이터가 INFORMATION_SCHEMA 에 저장되어있는 다른 데이터베이스 개체에 대한 정보를 얻을 수 있습니다.

또한 배포 된 권한을 사용하지 않으면, MySQL Cluster SQL 노드마다 다른 root 계정의 암호를 사용하는 것도 매우 적절한 방법입니다.

즉, MySQL Cluster가 로컬 네트워크 외부에서 직접 액세스 할 수있는 경우는 안전을 보장 할 수 없습니다.

중요

MySQL의 root 계정의 암호는 비워하지 마십시오. 이것은 MySQL을 MySQL Cluster SQL 노드로 실행하는 경우에도 독립형 (비 클러스터) MySQL 서버로 실행하는 경우에도 똑같이 적용, MySQL 설치 과정의 일부로 MySQL 서버를 MySQL Cluster의 SQL 노드로 구성하기 전에 실행하도록하십시오.

MySQL Cluster의 권한 배포 기능을 사용하려면 단순히 NDB 스토리지 엔진을 사용하도록 mysql 데이터베이스의 시스템 테이블을 수동으로 변환하지 마십시오. 대신이 목적을 위해 제공되는 저장 프로 시저를 사용하십시오. 섹션 18.5.14 "MySQL Cluster 배포 된 MySQL 권한" 을 참조하십시오.

그렇지 않으면, SQL 노드간에 mysql 시스템 테이블을 동기화 할 필요가있는 경우 표준 MySQL 복제를 사용하여이를 수행 할 스크립트를 사용하여 MySQL 서버간에 테이블 항목을 복사 수 있습니다.

요약 다음은 MySQL Cluster에 대해 MySQL 권한 시스템에 대해 기억해야 할 가장 중요한 점을 보여줍니다.

있는 SQL 노드에서 확립 된 사용자 및 권한은 클러스터의 다른 SQL 노드에서 자동으로 존재하거나 활성화 될 수 없습니다. 반대로 클러스터있는 SQL 노드에서 사용자 또는 권한을 삭제해도 다른 SQL 노드에서 사용자 또는 권한이 제거되지 않습니다.
SQL 스크립트 및 그에 포함 된 MySQL Cluster 배포에서이 목적으로 제공되는 저장 프로 시저를 사용하여 여러 MySQL 노드간에 SQL 사용자 및 권한을 배포 할 수 있습니다.
MySQL Cluster 내에있는 SQL 노드에서 MySQL 사용자에게 NDB 테이블에 대한 권한이 부여되면, 권한 분산을 사용하지 않는 경우에도 사용자는 데이터가 생성 된 SQL 노드에 관계없이 테이블 어떤 데이터도 "참조"할 수 있습니다.