डेटाबेस में यूज़र और परमिशन

root या postgres के रूप में चलने वाला एप्लिकेशन पहली ही कमज़ोरी पर मशीन के हर डेटाबेस को हमलावर के हवाले कर देता है। सिर्फ़ अपने स्कीमा पर अधिकारों वाला समर्पित यूज़र नुकसान को एक प्रोजेक्ट तक सीमित रखता है।

MySQL और MariaDB

यहाँ यूज़र “नाम और होस्ट” की जोड़ी होता है, और यही सबसे बड़ी उलझन की जड़ है:

CREATE USER 'shop'@'localhost' IDENTIFIED BY 'long-random-password';
GRANT SELECT, INSERT, UPDATE, DELETE ON shop.* TO 'shop'@'localhost';
FLUSH PRIVILEGES;

'shop'@'localhost' और 'shop'@'%' अलग-अलग पासवर्ड वाले दो अलग यूज़र हैं। ज़रूरत के बिना होस्ट % वाली रिकॉर्ड न बनाएँ: यह किसी भी पते से लॉगिन की इजाज़त देता है।

स्ट्रक्चर पर अधिकार सिर्फ़ माइग्रेशन के दौरान चाहिए:

GRANT CREATE, ALTER, DROP, INDEX, REFERENCES ON shop.* TO 'shop_migrate'@'localhost';

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

जाँचें:

SELECT user, host FROM mysql.user;
SHOW GRANTS FOR 'shop'@'localhost';

पासवर्ड बदलना और हटाना:

ALTER USER 'shop'@'localhost' IDENTIFIED BY 'new-password';
DROP USER 'shop'@'localhost';

PostgreSQL

रोल और डेटाबेस तथा स्कीमा पर उसके अधिकार:

CREATE ROLE shop WITH LOGIN PASSWORD 'long-random-password';
CREATE DATABASE shop OWNER shop;
REVOKE ALL ON DATABASE shop FROM PUBLIC;

रीड-ओनली रोल के लिए (रिपोर्ट, एनालिटिक्स, मॉनिटरिंग पैनल):

CREATE ROLE reader WITH LOGIN PASSWORD '...';
GRANT CONNECT ON DATABASE shop TO reader;
GRANT USAGE ON SCHEMA public TO reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO reader;

आख़िरी लाइन ज़रूरी है: इसके बिना रोल को अधिकार देने के बाद बनी टेबलें दिखेंगी नहीं, और एक महीने में रिपोर्ट नए डेटा पर टूट जाएँगी।

जाँचें:

\du
\l
\dp

क्या-क्या लॉक करना ज़रूरी है

• कोई भी एप्लिकेशन रोल सुपरयूज़र न हो।
• हर प्रोजेक्ट का अपना डेटाबेस और अपना यूज़र हो।
• पासवर्ड लंबे और रैंडम हों, और अलग-अलग प्रोजेक्ट के लिए अलग-अलग हों।
• बाहरी लॉगिन सिर्फ़ उन्हीं पतों के लिए हो जिन्हें इसकी ज़रूरत है — रिमोट एक्सेस।
• MySQL में कोई एनोनिमस यूज़र और कोई टेस्ट डेटाबेस न हो: mariadb-secure-installation यही करता है।

आम गलतियाँ

डेटाबेस पासवर्ड कोड में नहीं, बल्कि 600 परमिशन वाली सर्विस एनवायरनमेंट फ़ाइल में रखें। लीक होने पर आप एक लाइन बदलकर रीस्टार्ट करते हैं, पूरा प्रोजेक्ट दोबारा नहीं बनाते।