मारियाडीबी के लिए डेटाबेस रोल-बेस्ड एक्सेस कंट्रोल को लागू करने के लिए टिप्स और ट्रिक्स

डेटाबेस प्रबंधन प्रणाली (DBMS) में, भूमिका-आधारित अभिगम नियंत्रण (RBAC), विशेषाधिकारों के पूर्व-निर्धारित समूहों के एक सेट के आधार पर डेटाबेस संसाधनों पर प्रतिबंध है और मुख्य में से एक बन गया है। उन्नत अभिगम नियंत्रण के तरीके। डेटाबेस भूमिकाएँ बनाई और छोड़ी जा सकती हैं, साथ ही उन्हें दिए गए विशेषाधिकार और उनसे निरस्त किए जा सकते हैं। अलग-अलग उपयोगकर्ता खातों को भूमिकाएँ दी जा सकती हैं और उनसे निरस्त की जा सकती हैं। किसी खाते के लिए लागू सक्रिय भूमिकाएं खाते को दी गई भूमिकाओं में से चुनी जा सकती हैं और उस खाते के सत्रों के दौरान बदली जा सकती हैं।

इस ब्लॉग पोस्ट में, हम उपयोगकर्ता विशेषाधिकारों को प्रबंधित करने के लिए डेटाबेस भूमिका का उपयोग करने और हमारे डेटाबेस एक्सेस के लिए एक उन्नत एक्सेस कंट्रोल मैकेनिज्म के रूप में कुछ टिप्स और ट्रिक्स को कवर करेंगे। यदि आप MySQL और MariaDB में भूमिकाओं की मूल बातें जानना चाहते हैं, तो इस ब्लॉग पोस्ट को देखें, डेटाबेस उपयोगकर्ता प्रबंधन:मारियाडीबी के लिए भूमिकाएँ प्रबंधित करना।

MySQL बनाम MariaDB भूमिकाएं

MySQL और MariaDB दो अलग-अलग भूमिका तंत्रों का उपयोग करते हैं। MySQL 8.0 और बाद में, भूमिका अन्य उपयोगकर्ता के समान है, उपयोगकर्ता नाम और होस्ट ('रोल 1' @ 'लोकलहोस्ट') के साथ। हां, यह भूमिका का नाम है, जो व्यावहारिक रूप से मानक उपयोगकर्ता-होस्ट परिभाषा के समान है। MySQL भूमिका परिभाषा को उसी तरह संग्रहीत करता है जैसे mysql.user सिस्टम तालिका में उपयोगकर्ता विशेषाधिकारों को संग्रहीत करता है।

मारियाडीबी ने मारियाडीबी संस्करण 10.0.5 (नवंबर 2013) में भूमिका और पहुंच विशेषाधिकारों की शुरुआत की थी, यह एक अच्छा 8 साल पहले MySQL ने MySQL8.0 में इस सुविधा को शामिल किया था। यह SQL-अनुरूप डेटाबेस सिस्टम में समान भूमिका प्रबंधन का अनुसरण करता है, अधिक मजबूत और समझने में बहुत आसान। मारियाडीबी ने mysql.user सिस्टम टेबल में परिभाषा को एक नए जोड़े गए कॉलम के साथ चिह्नित किया है जिसे is_role कहा जाता है। मानक MySQL उपयोगकर्ता प्रबंधन के समान उपयोगकर्ता-होस्ट संयोजन का उपयोग करके MySQL भूमिका को अलग तरीके से संग्रहीत करता है।

ऐसा कहने के बाद, इन दो DBMS के बीच रोल माइग्रेशन अब एक दूसरे के साथ असंगत है।

MariaDB व्यवस्थापकीय और बैकअप भूमिकाएँ

MySQL में गतिशील विशेषाधिकार हैं, जो सामान्य प्रशासन कार्यों के लिए विशेषाधिकारों का एक सेट प्रदान करते हैं। मारियाडीबी के लिए, हम भूमिकाओं का उपयोग करके समान चीजें सेट कर सकते हैं, खासकर बैकअप के लिए और विशेषाधिकार बहाल करने के लिए। मारियाडीबी बैकअप के लिए, चूंकि यह एक भौतिक बैकअप है और इसके लिए विशेषाधिकारों के एक अलग सेट की आवश्यकता होती है, हम इसे किसी अन्य डेटाबेस उपयोगकर्ता को सौंपे जाने के लिए एक विशिष्ट भूमिका बना सकते हैं।

सबसे पहले, एक भूमिका बनाएं और उसे सही विशेषाधिकार प्रदान करें:

MariaDB> CREATE ROLE mariadb_backup;
MariaDB> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO mariadb_backup;

फिर हम बैकअप उपयोगकर्ता बना सकते हैं, इसे mariadb_backup भूमिका प्रदान कर सकते हैं और डिफ़ॉल्ट भूमिका असाइन कर सकते हैं:

MariaDB> CREATE USER [email protected] IDENTIFIED BY 'passw0rdMMM';
MariaDB> GRANT mariadb_backup TO [email protected];
MariaDB> SET DEFAULT ROLE mariadb_backup FOR [email protected];

mysqldump या mariadb-dump के लिए, बैकअप बनाने के लिए न्यूनतम विशेषाधिकार निम्नानुसार सेट किए जा सकते हैं:

MariaDB> CREATE ROLE mysqldump_backup;
MariaDB> GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES ON *.* TO mysqldump_backup;

फिर हम बैकअप उपयोगकर्ता बना सकते हैं, इसे mysqldump_backup भूमिका प्रदान कर सकते हैं और डिफ़ॉल्ट भूमिका असाइन कर सकते हैं:

MariaDB> CREATE USER [email protected] IDENTIFIED BY 'p4ss182MMM';
MariaDB> GRANT mysqldump_backup TO [email protected];
MariaDB> SET DEFAULT ROLE mysqldump_backup FOR [email protected];

बहाली के लिए, इसे आमतौर पर विशेषाधिकारों के एक अलग सेट की आवश्यकता होती है, जो कि थोड़ा सा है:

MariaDB> CREATE ROLE mysqldump_restore;
MariaDB> GRANT SUPER, ALTER, INSERT, CREATE, DROP, LOCK TABLES, REFERENCES, SELECT, CREATE ROUTINE, TRIGGER ON *.* TO mysqldump_restore;

फिर हम पुनर्स्थापना उपयोगकर्ता बना सकते हैं, इसे mysqldump_restore भूमिका के साथ प्रदान कर सकते हैं, और डिफ़ॉल्ट भूमिका असाइन कर सकते हैं:

MariaDB> CREATE USER [email protected] IDENTIFIED BY 'p4ss182MMM';
MariaDB> GRANT mysqldump_restore TO [email protected];
MariaDB> SET DEFAULT ROLE mysqldump_restore FOR [email protected];

इस ट्रिक का उपयोग करके हम पूर्व-निर्धारित विशेषाधिकारों के साथ एक भूमिका निर्दिष्ट करके प्रशासनिक उपयोगकर्ता निर्माण प्रक्रिया को सरल बना सकते हैं। इस प्रकार, हमारे GRANT स्टेटमेंट को छोटा और समझने में आसान बनाया जा सकता है।

MariaDB में रोल ओवर रोल बनाना 

हम नेस्टेड समूह सदस्यता के समान एक मौजूदा भूमिका पर एक और भूमिका बना सकते हैं जिसमें विशेषाधिकारों पर अधिक बारीक नियंत्रण हो। उदाहरण के लिए, हम निम्नलिखित 4 भूमिकाएँ बना सकते हैं:

MariaDB> CREATE ROLE app_developer, app_reader, app_writer, app_structure;

एप्लिकेशन_स्ट्रक्चर भूमिका के लिए स्कीमा संरचना को प्रबंधित करने के लिए विशेषाधिकार प्रदान करें:

MariaDB> GRANT CREATE, ALTER, DROP, CREATE VIEW, CREATE ROUTINE, INDEX, TRIGGER, REFERENCES ON app.* to app_structure;

डेटा हेरफेर भाषा (डीएमएल) के लिए ऐप_राइटर की भूमिका के लिए विशेषाधिकार प्रदान करें:

MariaDB> GRANT INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES app.* to app_writer;

app_reader भूमिका के लिए डेटा क्वेरी भाषा (DQL) के लिए विशेषाधिकार प्रदान करें:

MariaDB> GRANT SELECT, LOCK TABLES, SHOW VIEW app.* to app_reader;

और अंत में, हम उपरोक्त सभी भूमिकाओं को app_developer को सौंप सकते हैं, जिसका स्कीमा पर पूर्ण नियंत्रण होना चाहिए:

MariaDB> GRANT app_structure TO app_developer;
MariaDB> GRANT app_reader TO app_developer;
MariaDB> GRANT app_writer TO app_developer;

भूमिकाएं तैयार हैं और अब हम app_developer भूमिका के साथ एक डेटाबेस उपयोगकर्ता बना सकते हैं:

MariaDB> CREATE USER 'michael'@'192.168.0.%' IDENTIFIED BY 'passw0rdMMMM';
MariaDB> GRANT app_developer TO 'michael'@'192.168.0.%';
MariaDB> GRANT app_reader TO 'michael'@'192.168.0.%';

चूंकि माइकल अब app_deleloper और app_reader भूमिकाओं से संबंधित है, इसलिए हम उसे अवांछित मानवीय गलती से बचाने के लिए डिफ़ॉल्ट भूमिका के रूप में निम्नतम विशेषाधिकार भी प्रदान कर सकते हैं:

MariaDB> SET DEFAULT ROLE app_reader FOR 'michael'@'192.168.0.%';

एक भूमिका का उपयोग करने के बारे में अच्छी बात यह है कि आप डेटाबेस उपयोगकर्ता से वास्तविक विशेषाधिकार छिपा सकते हैं। निम्नलिखित डेटाबेस उपयोगकर्ता पर विचार करें जो अभी लॉग इन है:

MariaDB> SELECT user();
+----------------------+
| user()               |
+----------------------+
| [email protected] |
+----------------------+

शो अनुदान का उपयोग करके विशेषाधिकारों को पुनः प्राप्त करने का प्रयास करते समय, माइकल देखेंगे:

MariaDB> SHOW GRANTS FOR 'michael'@'192.168.0.%';
+----------------------------------------------------------------------------------------------------------------+
| Grants for [email protected]                                                                                   |
+----------------------------------------------------------------------------------------------------------------+
| GRANT `app_developer` TO `michael`@`localhost`                                                                 |
| GRANT USAGE ON *.* TO `michael`@`localhost` IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19' |
+----------------------------------------------------------------------------------------------------------------+

और जब माइकल ऐप_डेवलपर के विशेषाधिकारों की तलाश कर रहा होता है, तो उसे यह त्रुटि दिखाई देगी:

MariaDB> SHOW GRANTS FOR FOR app_developer;
ERROR 1044 (42000): Access denied for user 'michael'@'localhost' to database 'mysql'

यह ट्रिक डीबीए को केवल उस तार्किक समूह को प्रदर्शित करने की अनुमति देती है जहां उपयोगकर्ता संबंधित है और इससे अधिक कुछ नहीं। हम इस पहलू से हमले के वेक्टर को कम कर सकते हैं क्योंकि उपयोगकर्ताओं को वास्तविक विशेषाधिकारों के बारे में पता नहीं होगा जो उन्हें सौंपे जा रहे हैं।

MariaDB में डिफ़ॉल्ट भूमिका लागू करना

एक डिफ़ॉल्ट भूमिका लागू करके, एक डेटाबेस उपयोगकर्ता को पहली परत पर आकस्मिक मानवीय गलतियों से बचाया जा सकता है। उदाहरण के लिए, उपयोगकर्ता माइकल पर विचार करें जिसे ऐप_डेवलपर भूमिका प्रदान की गई है, जहां ऐप_डेवलपर भूमिका ऐप_स्ट्रुकुट्रे, ऐप_राइटर और ऐप_रीडर भूमिकाओं का एक सुपरसेट है, जैसा कि नीचे दिखाया गया है:

चूंकि माइकल ऐप_डेलीपर भूमिका से संबंधित है, इसलिए हम निम्नतम विशेषाधिकार भी सेट कर सकते हैं उसे आकस्मिक डेटा संशोधन से बचाने के लिए डिफ़ॉल्ट भूमिका के रूप में:

MariaDB> GRANT app_reader TO 'michael'@'192.168.0.%';
MariaDB> SET DEFAULT ROLE app_reader FOR 'michael'@'192.168.0.%';

उपयोगकर्ता "माइकल" के लिए, वह एक बार लॉग इन करने के बाद निम्नलिखित देखेंगे:

MariaDB> SELECT user(),current_role();
+-------------------+----------------+
| user()            | current_role() |
+-------------------+----------------+
| [email protected] | app_reader     |
+-------------------+----------------+

इसकी डिफ़ॉल्ट भूमिका app_reader है, जो "ऐप" नामक डेटाबेस के लिए केवल पढ़ने के लिए विशेषाधिकार है। वर्तमान उपयोगकर्ता के पास SET ROLE सुविधा का उपयोग करके किसी भी लागू भूमिकाओं के बीच स्विच करने की क्षमता है। जहां तक ​​माइकल का सवाल है, वह निम्नलिखित कथन का उपयोग करके किसी अन्य भूमिका में स्विच कर सकता है:

MariaDB> SET ROLE app_developer;

इस बिंदु पर, माइकल डेटाबेस 'ऐप' को लिखने में सक्षम होना चाहिए क्योंकि ऐप_डेवलपर ऐप_राइटर और ऐप_स्ट्रक्चर का सुपरसेट है। वर्तमान उपयोगकर्ता के लिए उपलब्ध भूमिकाओं की जाँच करने के लिए, हम info_schema.applicable_roles तालिका को क्वेरी कर सकते हैं:

MariaDB> SELECT * FROM information_schema.applicable_roles;
+-------------------+---------------+--------------+------------+
| GRANTEE           | ROLE_NAME     | IS_GRANTABLE | IS_DEFAULT |
+-------------------+---------------+--------------+------------+
| [email protected] | app_developer | NO           | NO         |
| app_developer     | app_writer    | NO           | NULL       |
| app_developer     | app_reader    | NO           | NULL       |
| app_developer     | app_structure | NO           | NULL       |
| [email protected] | app_reader    | NO           | YES        |
+-------------------+---------------+--------------+------------+

इस तरह, हम उपयोगकर्ता के लिए एक प्राथमिक भूमिका निर्धारित कर रहे हैं, और प्राथमिक भूमिका किसी विशिष्ट उपयोगकर्ता के लिए संभव न्यूनतम विशेषाधिकार हो सकती है। डेटाबेस सर्वर पर किसी भी जोखिम भरी गतिविधि को निष्पादित करने से पहले उपयोगकर्ता को अपनी सक्रिय भूमिका के बारे में सहमति देनी होगी, किसी अन्य विशेषाधिकार प्राप्त भूमिका पर स्विच करके।

मारियाडीबी में रोल मैपिंग

MariaDB एक भूमिका मानचित्रण तालिका प्रदान करता है जिसे mysql.roles_mapping कहा जाता है। मैपिंग हमें उपयोगकर्ता और उसकी भूमिकाओं के बीच के संबंध को आसानी से समझने की अनुमति देती है, और कैसे एक भूमिका को दूसरी भूमिका में मैप किया जाता है:

MariaDB> SELECT * FROM mysql.roles_mapping;
+-------------+-------------------+------------------+--------------+
| Host        | User              | Role             | Admin_option |
+-------------+-------------------+------------------+--------------+
| localhost   | root              | app_developer    | Y            |
| localhost   | root              | app_writer       | Y            |
| localhost   | root              | app_reader       | Y            |
| localhost   | root              | app_structure    | Y            |
|             | app_developer     | app_structure    | N            |
|             | app_developer     | app_reader       | N            |
|             | app_developer     | app_writer       | N            |
| 192.168.0.% | michael           | app_developer    | N            |
| localhost   | michael           | app_developer    | N            |
| localhost   | root              | mysqldump_backup | Y            |
| localhost   | dump_user1        | mysqldump_backup | N            |
| localhost   | root              | mariadb_backup   | Y            |
| localhost   | mariabackup_user1 | mariadb_backup   | N            |
+-------------+-------------------+------------------+--------------+

उपरोक्त आउटपुट से, हम बता सकते हैं कि होस्ट के बिना एक उपयोगकर्ता मूल रूप से एक भूमिका पर एक भूमिका है और प्रशासनिक उपयोगकर्ताओं (Admin_option =Y) को भी स्वचालित रूप से बनाई गई भूमिकाओं को सौंपा जा रहा है। निर्मित भूमिकाओं की सूची प्राप्त करने के लिए, हम MySQL उपयोगकर्ता तालिका को क्वेरी कर सकते हैं:

MariaDB> SELECT user FROM mysql.user WHERE is_role = 'Y';
+------------------+
| User             |
+------------------+
| app_developer    |
| app_writer       |
| app_reader       |
| app_structure    |
| mysqldump_backup |
| mariadb_backup   |
+------------------+

अंतिम विचार

भूमिकाओं का उपयोग डेटाबेस उपयोगकर्ताओं द्वारा आकस्मिक डेटा संशोधन के खिलाफ सुरक्षा की एक अतिरिक्त परत प्रदान करके डेटाबेस सुरक्षा में सुधार कर सकता है। इसके अलावा, यह उन संगठनों के लिए विशेषाधिकार प्रबंधन और रखरखाव संचालन को सरल करता है जिनके पास कई डेटाबेस उपयोगकर्ता हैं।