일반 사용자에게 부여 할 수있는 합리적인 권한은 무엇입니까? [닫은]

MySQL 이 제공하는 권한 목록이 약간 압도적이라는 것을 알았습니다 . 누가 어떤 권한을 가져야하는지 잘 모르겠습니다. 내 마음에 내 상황에 대한 세 가지 일반적인 사용자가 있습니다.

1. root
2. developer
3. application

root자명하다. 를 들어 developer이 사용자의 요구가 쉽게 나는이 권한 세트에이 사용자 설정에있어 우선 등, 여기에 모든 데이터베이스, 메이크업 조정에 액세스 할 수 있도록 :

SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON

application훨씬 더 제한된 세트가 있습니다. 특정 데이터베이스를 조작하는 것으로 제한되어야합니다.

합리적인 권한이 부여되는 것이 확실하지 않습니다. 개발자와 응용 프로그램을 부여 할 수있는 합리적인 권한은 무엇이며 그 이유는 무엇입니까?

일반적인 사용자에게는 다음이 있어야합니다.

SELECT, INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES, EXECUTE

처음 네 개는 꽤 분명하지만 "읽기 전용"사용자 만 설정할 수도 있습니다 SELECT.

CREATE TEMPORARY임시 테이블은 쿼리를 최적화하여 더 작고 빠른 부분으로 나누는 데 도움이됩니다. 실행중인 연결로 제한되며 연결이 닫히면 자동으로 삭제됩니다.

EXECUTE시스템 유형에 따라 다릅니다. 루틴을 저장 했습니까? 사용자가 액세스하도록 하시겠습니까? SECURITY=DEFINER/INVOKER스토어드 루틴 의 정의에 대해서도 알고 있어야 합니다.

어쨌든 위의 모든 것을 특정 스키마 에 적용하십시오 . 사용 하지 마십시오 :

GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'some_user'@'some_host';

위와 같이 mysql시스템 테이블 에 대한 권한도 부여 하므로 모든 사용자가 효과적으로 새 계정을 만들거나 자신의 권한 집합을 업그레이드 할 수 있습니다. 대신 다음을 수행하십시오.

GRANT SELECT, INSERT, UPDATE, DELETE ON some_schema.* TO 'some_user'@'some_host';
GRANT SELECT, INSERT, UPDATE, DELETE ON another_schema.* TO 'some_user'@'some_host';

실제 프로젝트 (개인 프로젝트가 아닌)에서 이러한 사용자 유형은 환경에 따라 다양하므로 그렇게 간단하지 않습니다.

모든 환경에서 응용 프로그램은 필요한 것 이상을 가져야합니다 (일반적으로 "모든 테이블에서 선택 / 삽입 / 업데이트"및 "모든 프로 시저에서 실행"입니다). 다른 작업에 대해 별도의 응용 프로그램 사용자가있는 대규모 시스템 예를 들어, 한 응용 프로그램은 검열 데이터를 제공하고 다른 응용 프로그램은 보고서를 생성해야합니다.) 권한이 가장 적은 권한을 분리해야합니다 (보고 사용자는 필요하지 않고 쓰기 권한이있을 수 있음). 테스트 환경에서 모든 것이 sa(MSSQL과 동등한 root) DB에 액세스했기 때문에 테스트로 작동하는 Live로 승격 할 때 코드가 넘어지는 것을 보았습니다 .이상적으로 응용 프로그램 사용자는 일반적으로 스키마를 변경할 수있는 권한이 없어야합니다 (CREATE,, DROP...)-여기에는 예외가 있지만 그 사이에는 거의 없습니다.

root글쎄요 root. 프로덕션 환경에서는 DBA 만 사용되며 시스템 유지 관리 (DB 디자인 등으로 업그레이드) 및 모니터링 용도로만 사용해서는 안됩니다. 대규모 시스템의 경우, 특히 책임을 수행하기 위해 개인을 면밀히 제어해야하는 규제 환경에서는 단일 root사용자를 전혀 허용하지 않고 권한을 더 작은 롤로 분리하려고 할 수 있습니다 (얼마나 멀리 갈 수 있는지 잘 모르겠습니다) mysql에서는 이것을 사용하지만 MSSQL, Oracle 등에서는 상당히 세분화 될 수 있습니다).

개발자 사용자의 경우 : 실제 환경에 전혀 액세스 할 수 없어야합니다. 이는 응용 프로그램 사용자에게 권한에 영향을 미치는 스키마가 없어야하는 이유 중 하나입니다. 개발자 계정에 액세스 할 수있는 사람은 이러한 방식으로 잠금을 우회 할 수 있습니다. 테스트 환경에서도 일반적으로 액세스 권한이 없습니다. QA에 패치를 제출하고 QA 용 DBA (아마도 root사용자를 사용함 )는 테스트 환경에 업데이트를 적용합니다 (실제로 이는 대규모 조직에서 자동화되기 때문에 QA DBA 실제로는 각주기마다 테스트 환경을 재구성하는 것을 제어하는 ​​스크립트 세트입니다. 개발 환경에서, 특히 개발자가 자체 로컬 실행 서비스 사본을 보유하고있는 경우, 이러한 사용자는 실험을 수행 할 수 있도록 모든 것에 액세스 할 수 있어야합니다.

위의 내용은 일반적인 참고 사항입니다. 특정 권장 사항을 적용하려면 응용 프로그램 및 응용 프로그램이 작동하는 환경에 대해 훨씬 더 알아야합니다. 대상 환경은 생각보다 중요합니다. 비즈니스 환경에 따라 고객이 진단 목적으로 실제 데이터에 액세스 할 수있는 경우에도 개발중인 경우에도 사용자의 권리는 법적으로 직접 규정 될 수 있습니다.