Oracle ডেটাবেজ সিকিউরিটি ও হার্ডেনিং: Least Privilege, TDE, Database Vault, Auditing ও Patching

ডেটাবেজ breach খুব কমই হলিউড-স্টাইলের হ্যাক। বাস্তব প্রোডাকশন পরিবেশে এটা আরও অনেক সাধারণ ঘটনা: একটা শেয়ার্ড DBA অ্যাকাউন্ট যার পাসওয়ার্ড কখনও বদলায় না, একজন ডেভেলপার যিনি প্রজেক্ট ছেড়ে যাওয়ার দুই বছর পরেও প্রোডাকশন salary টেবিলে SELECT অধিকার ধরে রেখেছেন, একটা encrypt না-করা backup টেপ যা কোনো আলমারিতে পড়ে আছে, কিংবা একটা audit trail যা কেউ কখনও পড়েই না। Oracle ডেটাবেজ জগতের অন্যতম পরিপূর্ণ সিকিউরিটি টুলকিট নিয়েই আসে — Transparent Data Encryption, Database Vault, Unified Auditing, Data Redaction, fine-grained access control — অথচ আমাকে যেসব ডেটাবেজ রিভিউ করতে বলা হয় তার বেশিরভাগই এর প্রায় কিছুই ব্যবহার করে না। এই গাইডে আমি একটি বাস্তবমুখী, স্তরভিত্তিক (layered) হার্ডেনিং methodology তুলে ধরছি, যা ম্যানুফ্যাকচারিং, ব্যাংকিং ও ফার্মাসিউটিক্যাল পরিবেশে প্রোডাকশন Oracle ডেটাবেজে আমি প্রয়োগ করি — সঠিক কমান্ডসহ এবং প্রতিটি control-এর পেছনের যুক্তিসহ।

১. সঠিক মডেল: Defense in Depth

সিকিউরিটি এমন একটা সুইচ নয় যা একবার চেপে দিলেই হলো। এটা কয়েকটা স্বাধীন স্তরের সমন্বয়, যার প্রতিটির ভেতর দিয়ে একজন আক্রমণকারীকে — কিংবা একটা সৎ ভুলকে — পার হতে হয়। একটা স্তর ব্যর্থ হলেও পরের স্তর আপনাকে রক্ষা করে। একটা Oracle ডেটাবেজের জন্য যে স্তরগুলো গুরুত্বপূর্ণ:

1. Access control: কে connect করতে পারবে, আর প্রতিটি অ্যাকাউন্ট কী কী করতে পারবে? (least privilege, roles, password profiles)
2. Encryption at rest: কেউ যদি একটা datafile বা backup চুরি করে, সেটা কি তার কাছে অকেজো থাকবে? (TDE)
3. Encryption in transit: অ্যাপ্লিকেশন ও ডেটাবেজের মধ্যে নেটওয়ার্কে কেউ কি ডেটা sniff করতে পারবে? (native network encryption / TLS)
4. Separation of duties: একজন DBA কি যে business data সে অ্যাডমিনিস্টার করে তা পড়তে পারবে? (Database Vault)
5. Accountability: প্রতিটি privileged action কি রেকর্ড করা ও পর্যালোচনাযোগ্য? (Unified Auditing)
6. Data minimisation: ইউজাররা কি এমন sensitive column দেখছে যা তাদের দরকার নেই? (Data Redaction)
7. Patching: পরিচিত vulnerability কি দ্রুত বন্ধ করা হচ্ছে? (quarterly Critical Patch Updates)

সবচেয়ে বড় ভুল যা আমি দেখি তা হলো টিমগুলো একটা স্তরে — সাধারণত একটা network firewall-এ — প্রচুর বিনিয়োগ করে, অথচ তার পেছনে ডেটাবেজটিকে পুরোপুরি খোলা রেখে দেয়। যে contractor-এর কাছে ইতিমধ্যে একটা বৈধ login আর প্রয়োজনের চেয়ে বেশি privilege আছে, তার বিরুদ্ধে একটা firewall কিছুই করতে পারে না।

২. Least Privilege ও User Management

ডেটাবেজ সিকিউরিটির ভিত্তি হলো প্রতিটি অ্যাকাউন্টের কাছে ঠিক ততটুকুই privilege থাকবে যতটা তার কাজের জন্য দরকার, এর বেশি নয়। এই control-ই সবচেয়ে বেশি ক্ষতি ঠেকায়, আর এতে শৃঙ্খলা ছাড়া আর কোনো খরচ নেই।

২.১ Over-Privileged অ্যাকাউন্ট খুঁজে বের করুন

-- Who has powerful system privileges directly granted?
SELECT grantee, privilege, admin_option
FROM DBA_SYS_PRIVS
WHERE privilege IN ('SELECT ANY TABLE','UPDATE ANY TABLE','DELETE ANY TABLE',
                    'ALTER ANY TABLE','DROP ANY TABLE','CREATE ANY PROCEDURE',
                    'EXECUTE ANY PROCEDURE','GRANT ANY ROLE','GRANT ANY PRIVILEGE')
ORDER BY grantee, privilege;

-- Who has the DBA role (should be a very short list)?
SELECT grantee FROM DBA_ROLE_PRIVS
WHERE granted_role = 'DBA'
ORDER BY grantee;

-- Accounts that can log in but have never been used recently
SELECT username, account_status, last_login, profile
FROM DBA_USERS
WHERE account_status = 'OPEN'
ORDER BY last_login NULLS FIRST;

ওই প্রথম দুটি query-তে যে প্রতিটি নাম আসবে, তার প্রতিটিই যৌক্তিক হওয়া উচিত। ANY privilege বিশেষভাবে বিপজ্জনক — SELECT ANY TABLE একটা অ্যাকাউন্টকে ডেটাবেজের প্রতিটি টেবিল পড়তে দেয়, data dictionary ও অন্যান্য schema-সহ। এর বদলে নির্দিষ্ট টেবিলের ওপর object privilege দিন।

২.২ Default ও অব্যবহৃত অ্যাকাউন্ট লক করুন

-- Lock and expire any sample / default account that is open
ALTER USER hr ACCOUNT LOCK;
ALTER USER scott ACCOUNT LOCK;

-- Revoke EXECUTE on powerful packages from PUBLIC
REVOKE EXECUTE ON UTL_FILE FROM PUBLIC;
REVOKE EXECUTE ON UTL_TCP FROM PUBLIC;
REVOKE EXECUTE ON UTL_HTTP FROM PUBLIC;
REVOKE EXECUTE ON DBMS_SCHEDULER FROM PUBLIC;

২.৩ Password Profile বাধ্যতামূলক করুন

ডেটাবেজ দ্বারা প্রয়োগ করা একটা পাসওয়ার্ড নীতি, কেউ মানে না এমন একটা ডকুমেন্টে লেখা নীতির চেয়ে অনেক শক্তিশালী।

-- Create a strong profile and assign it to application/DBA accounts
CREATE PROFILE app_secure_profile LIMIT
  FAILED_LOGIN_ATTEMPTS     5
  PASSWORD_LIFE_TIME       90
  PASSWORD_REUSE_MAX       10
  PASSWORD_REUSE_TIME     365
  PASSWORD_LOCK_TIME        1
  PASSWORD_GRACE_TIME       7
  PASSWORD_VERIFY_FUNCTION ORA12C_STRONG_VERIFY_FUNCTION
  INACTIVE_ACCOUNT_TIME    60;

ALTER USER erp_app PROFILE app_secure_profile;

INACTIVE_ACCOUNT_TIME সেটিংটি ৬০ দিন ধরে অব্যবহৃত যেকোনো অ্যাকাউন্ট স্বয়ংক্রিয়ভাবে লক করে দেয় — এটাই একাই সবচেয়ে সাধারণ দরজাগুলোর একটি বন্ধ করে দেয়, সেই ভুলে-যাওয়া contractor login।

৩. Transparent Data Encryption (TDE) — Encryption at Rest

TDE ডেটাকে disk-এ লেখার সময় encrypt করে আর পড়ার সময় decrypt করে, অ্যাপ্লিকেশনের কাছে সম্পূর্ণ স্বচ্ছভাবে। কেউ যদি একটা datafile, একটা RMAN backup, বা একটা export চুরি করে, encryption key ছাড়া সেই ডেটা পড়ার অযোগ্য। ব্যক্তিগত, আর্থিক বা স্বাস্থ্য-সম্পর্কিত ডেটা রাখে এমন যেকোনো ডেটাবেজের জন্য TDE আর ঐচ্ছিক নয় — এটা প্রতিটি regulator ও প্রতিটি গুরুত্বপূর্ণ ক্লায়েন্টের একটি বেসলাইন প্রত্যাশা।

৩.১ Keystore কনফিগার করুন

-- In the database parameter file, point to the keystore location
ALTER SYSTEM SET WALLET_ROOT='/u01/app/oracle/admin/PRODDB/wallet' SCOPE=SPFILE;
-- restart, then:
ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=FILE" SCOPE=BOTH;

-- Create and open the software keystore
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE IDENTIFIED BY "StrongKeystorePwd#26";
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "StrongKeystorePwd#26";

-- Set the master encryption key
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "StrongKeystorePwd#26" WITH BACKUP;

-- Create an auto-login keystore so the DB opens without manual key entry
ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE
  IDENTIFIED BY "StrongKeystorePwd#26";

৩.২ Tablespace Encrypt করুন

-- Encrypt a new tablespace
CREATE TABLESPACE erp_secure_data
  DATAFILE '/u02/oradata/PRODDB/erp_secure01.dbf' SIZE 2G
  ENCRYPTION USING 'AES256' ENCRYPT;

-- Online-encrypt an existing tablespace (19c+ — no downtime)
ALTER TABLESPACE erp_data ENCRYPTION ONLINE USING 'AES256' ENCRYPT
  FILE_NAME_CONVERT=('erp_data','erp_data_enc');

-- Verify what is encrypted
SELECT tablespace_name, encrypted FROM DBA_TABLESPACES ORDER BY 1;

অত্যন্ত গুরুত্বপূর্ণভাবে, keystore backup ডেটাবেজ backup থেকে আলাদা কোনো জায়গায় রাখুন। key হারালে encrypt-করা ডেটা চিরতরে চলে যায় — এটাই তো encryption-এর মূল উদ্দেশ্য, আর এটা দুই দিকেই কাটে।

৪. Network Encryption — Encryption in Transit

ডেটা যতটা disk-এ পড়ে থাকা অবস্থায় উন্মুক্ত, ঠিক ততটাই উন্মুক্ত নেটওয়ার্কে চলাচলের সময়ও। network encryption ছাড়া, অ্যাপ্লিকেশন সার্ভার ও ডেটাবেজের মধ্যকার traffic যে-কেউ capture করতে পারে, সে query result এমনকি credential-ও পড়তে পারে। Oracle Native Network Encryption-এর জন্য কোনো certificate লাগে না এবং কয়েকটি sqlnet.ora সেটিং দিয়েই এটা চালু করা যায়।

# sqlnet.ora on both database and client side
SQLNET.ENCRYPTION_SERVER = REQUIRED
SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192)
SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256)

-- Confirm a session is actually encrypted
SELECT s.sid, n.network_service_banner
FROM V$SESSION_CONNECT_INFO n
JOIN V$SESSION s ON s.sid = n.sid
WHERE n.network_service_banner LIKE '%Encryption%'
  AND s.sid = SYS_CONTEXT('USERENV','SID');

ENCRYPTION_SERVER = REQUIRED সেট করার মানে হলো ডেটাবেজ এমন যেকোনো connection প্রত্যাখ্যান করবে যা encryption negotiate করবে না — শেয়ার্ড নেটওয়ার্কে থাকা একটি প্রোডাকশন সিস্টেমের জন্য এটাই সবচেয়ে নিরাপদ সেটিং।

৫. Database Vault — Separation of Duties

এখানে একটা অস্বস্তিকর সত্য যা বেশিরভাগ প্রতিষ্ঠান কখনও মোকাবিলা করে না: SYSDBA থাকা একজন DBA business data-র প্রতিটি row পড়তে পারে — salary, patient record, account balance — যদিও তার কাজ ডেটাবেজ চালু রাখা, এর বিষয়বস্তু দেখা নয়। একটা নিয়ন্ত্রিত (regulated) পরিবেশে এটা একটা প্রকৃত compliance ফাঁক। Oracle Database Vault এটার সমাধান করে realm তৈরি করে, যা এমনকি শক্তিশালী অ্যাকাউন্টকেও সুরক্ষিত ডেটা অ্যাক্সেস করা থেকে আটকায়।

-- After enabling Database Vault, create a realm around sensitive schemas
BEGIN
  DBMS_MACADM.CREATE_REALM(
    realm_name    => 'HR Salary Realm',
    description   => 'Protect HR salary and personal data from DBAs',
    enabled       => DBMS_MACUTL.G_YES,
    audit_options => DBMS_MACUTL.G_REALM_AUDIT_FAIL);

  DBMS_MACADM.ADD_OBJECT_TO_REALM(
    realm_name   => 'HR Salary Realm',
    object_owner => 'HR',
    object_name  => '%',
    object_type  => '%');
END;
/

এর পরে, এমনকি SELECT ANY TABLE বা SYSDBA থাকা একজন ইউজারকেও HR schema অ্যাক্সেস করতে দেওয়া হয় না, যদি না সে একজন অনুমোদিত realm participant হয়। অ্যাডমিনিস্ট্রেটর তখনও ডেটাবেজ backup, tune ও patch করতে পারে — সে শুধু সুরক্ষিত business data পড়তে পারে না। ব্যাংক ও ফার্মা auditor-রা ঠিক এই control-ই খোঁজে।

৬. Unified Auditing — Accountability

কিছু একটা ভুল হলে, আপনি কি "কে এটা করেছে, আর কখন?" — এই প্রশ্নের উত্তর দিতে পারবেন? Unified Auditing (আধুনিক audit framework, যা পুরনো AUD$ পদ্ধতির প্রতিস্থাপক) privileged কার্যক্রমকে একটি একক, নিরাপদ, tamper-resistant trail-এ ধরে রাখে অত্যন্ত কম overhead-এ, কারণ এটা সবকিছু ধরে রাখার বদলে policy-ভিত্তিক।

-- Audit all activity by powerful users and all privilege/role changes
CREATE AUDIT POLICY priv_user_activity
  ACTIONS ALL
  WHEN 'SYS_CONTEXT(''USERENV'',''CURRENT_USER'') IN (''SYSTEM'',''DBA_OPS'')'
  EVALUATE PER STATEMENT;

CREATE AUDIT POLICY ddl_and_grants
  ACTIONS CREATE USER, ALTER USER, DROP USER, GRANT, REVOKE,
          CREATE ROLE, ALTER PROFILE;

-- Audit failed logins (detect brute-force attempts)
CREATE AUDIT POLICY failed_logons ACTIONS LOGON;

AT POLICY priv_user_activity;
AUDIT POLICY ddl_and_grants;
AUDIT POLICY failed_logons WHENEVER NOT SUCCESSFUL;

-- Review the audit trail — failed logins in the last 24 hours
SELECT dbusername, action_name, return_code,
       TO_CHAR(event_timestamp,'DD-MON HH24:MI') AS when_happened,
       userhost, terminal
FROM UNIFIED_AUDIT_TRAIL
WHERE event_timestamp > SYSTIMESTAMP - 1
  AND action_name = 'LOGON'
  AND return_code <> 0
ORDER BY event_timestamp DESC;

যে audit trail কেউ পড়ে না, সেটা শুধু disk-এর জায়গা দখল করে থাকে। আসল control হলো failed login, privilege grant ও sensitive object-এ অ্যাক্সেসের একটি সংক্ষিপ্ত সাপ্তাহিক পর্যালোচনা — সপ্তাহে মাত্র দশ মিনিটও যেসব anomaly গুরুত্বপূর্ণ, সেগুলো ধরে ফেলে।

৭. Data Redaction — শুধু যতটুকু দরকার ততটুকুই দেখানো

প্রায়ই সমস্যাটা এই নয় যে একজন ইউজারের কোনো টেবিলে শূন্য অ্যাক্সেস থাকা উচিত, বরং এই যে তার একটি sensitive column পুরোপুরি দেখা উচিত নয়। একজন support agent-এর হয়তো পুরো national ID না দেখেই তার শেষ চারটি সংখ্যা নিশ্চিত করা দরকার। Data Redaction query-র সময় column value mask করে, stored ডেটায় কোনো পরিবর্তন ছাড়াই এবং অ্যাপ্লিকেশন কোড পরিবর্তন ছাড়াই।

-- Show only the last 4 digits of a national ID to non-privileged users
BEGIN
  DBMS_REDACT.ADD_POLICY(
    object_schema => 'HR',
    object_name   => 'EMPLOYEES',
    column_name   => 'NATIONAL_ID',
    policy_name   => 'redact_national_id',
    function_type => DBMS_REDACT.PARTIAL,
    function_parameters => 'VVVVVVVVV,VVVVVVVVV,*,1,9',
    expression    => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') NOT IN (''HR_MANAGER'')');
END;
/

HR manager পুরো value দেখে; বাকি সবাই একটি masked value দেখে — একই টেবিল থেকে, রক্ষণাবেক্ষণের জন্য কোনো duplicate "masked" কপি ছাড়াই।

৮. Patching — পরিচিত Vulnerability বন্ধ করা

Oracle প্রতি ত্রৈমাসিক চক্রে (Critical Patch Update) Release Update (RU) ও security fix প্রকাশ করে। ডেটাবেজ vulnerability-র সবচেয়ে বেশি exploit হওয়া শ্রেণিটি এমন একটি, যার জন্য fix ইতিমধ্যেই পাওয়া যাচ্ছিল কিন্তু কখনও প্রয়োগ করা হয়নি। একটা patching শৃঙ্খলা নিজেই একটি সিকিউরিটি control:

• আপনার বর্তমান patch level ট্র্যাক করুন: SELECT * FROM DBA_REGISTRY_SQLPATCH ORDER BY action_time DESC;
• একটা অনুমানযোগ্য ত্রৈমাসিক সূচি অনুযায়ী RU প্রয়োগ করুন, আগে non-production-এ পরীক্ষা করে।
• একটা rolling পদ্ধতির মাধ্যমে near-zero downtime-এ patch করতে একটি standby ডেটাবেজ (Data Guard) ব্যবহার করুন।
• প্রতিটি ডেটাবেজ ও তার patch level-এর একটি inventory রাখুন — যা আপনি ক্যাটালগ করেননি তা আপনি সুরক্ষিত করতে পারবেন না।

৯. একটি বাস্তবমুখী হার্ডেনিং চেকলিস্ট

Control	কী যাচাই করবেন	অগ্রাধিকার
Default পাসওয়ার্ড	কোনো অ্যাকাউন্ট পরিচিত default ব্যবহার করছে না (DBA_USERS_WITH_DEFPWD যাচাই করুন)	Critical
Least privilege	কোনো অযৌক্তিক ANY privilege বা DBA grant নেই	Critical
Encryption at rest	sensitive ডেটা রাখা tablespace-এ TDE	High
Encryption in transit	Native network encryption REQUIRED	High
Auditing	Unified Auditing চালু, trail সাপ্তাহিক পর্যালোচিত	High
Listener security	Listener password / local OS auth, কোনো remote admin নেই	Medium
Patching	ত্রৈমাসিক Release Update প্রয়োগ ও ট্র্যাক করা	High

১০. বাস্তব সিকিউরিটি কেস

প্রোডাকশন রিভিউ থেকে দুটি anonymised উদাহরণ:

কেস ১ — সেই ভুলে-যাওয়া Contractor অ্যাকাউন্ট

যা পাওয়া গেল: একটি ম্যানুফ্যাকচারিং গ্রুপে privilege রিভিউতে এমন একটি অ্যাকাউন্ট বেরিয়ে এলো যা একজন integration contractor-এর, যার প্রজেক্ট ১৮ মাস আগেই শেষ হয়ে গিয়েছিল। অ্যাকাউন্টটি তখনও খোলা ছিল, এতে SELECT ANY TABLE ছিল, এবং এর পাসওয়ার্ড কখনও expire করেনি।

সমাধান: অ্যাকাউন্টটি সঙ্গে সঙ্গে লক করা হলো, ANY privilege সরিয়ে ফেলা হলো, এবং সব অ্যাপ্লিকেশন অ্যাকাউন্টে একটি INACTIVE_ACCOUNT_TIME password profile প্রয়োগ করা হলো যাতে ভবিষ্যতে কোনো dormant login ৬০ দিন পরে স্বয়ংক্রিয়ভাবে লক হয়ে যায়। operations ক্যালেন্ডারে একটি ত্রৈমাসিক privilege রিভিউ যোগ করা হলো।

কেস ২ — একটি ফার্মা ডেটাবেজের Unencrypted Backup

যা পাওয়া গেল: একটি ফার্মাসিউটিক্যাল ক্লায়েন্টের RMAN backup encrypt না করে একটি network share-এ লেখা হচ্ছিল, যা পুরো IT টিমের কাছে accessible ছিল — অর্থাৎ file অ্যাক্সেস আছে এমন যে-কারও কাছে কার্যত regulated প্রোডাকশন ডেটার একটি সম্পূর্ণ কপি ছিল।

সমাধান: sensitive tablespace-গুলোতে TDE চালু করা হলো এবং RMAN backup encryption কনফিগার করা হলো, ফলে live datafile ও প্রতিটি backup এখন keystore ছাড়া অকেজো। keystore backup আলাদা, restricted হেফাজতে সরিয়ে নেওয়া হলো — যা পরবর্তী regulatory inspection-এর data-integrity প্রত্যাশা পূরণ করে।

১১. সাধারণ হার্ডেনিং ভুল

অনেক রিভিউ জুড়ে, একই এড়ানো-যায় এমন ভুলগুলো বারবার ফিরে আসে। এগুলোর দিকে খেয়াল রাখুন, কারণ প্রতিটিই তার চারপাশের control-গুলোকে নীরবে ভেঙে ফেলে:

• TDE keystore backup-এর সঙ্গে রাখা। datafile encrypt করা অর্থহীন যদি key সেই একই backup set-এ ভ্রমণ করে যা একজন আক্রমণকারী চুরি করবে। keystore হেফাজত আলাদা ও restricted রাখুন।
• "সময় বাঁচাতে" role দিয়ে দেওয়া। শুক্রবারে একজন ডেভেলপারকে আটকে যাওয়া থেকে মুক্ত করতে DBA role হাতে ধরিয়ে দেওয়া — এভাবেই over-privilege স্থায়ী হয়ে যায়। যে নির্দিষ্ট privilege দরকার সেটাই দিন, আর কাজ শেষ হলে তা সরিয়ে ফেলুন।
• Auditing চালু করা কিন্তু কখনও তা না পড়া। একটা audit trail কেবল তখনই একটা detection control, যখন কেউ তা পর্যালোচনা করে। failed login ও privilege grant-এর একটি সংক্ষিপ্ত, নিয়মিত পর্যালোচনা সূচি করুন — automation আপনার জন্য anomaly-গুলো সামনে এনে দিতে পারে।
• Listener পুরোপুরি খোলা রেখে দেওয়া। একটি অরক্ষিত listener remote reconnaissance এবং পুরনো version-এ remote administration-এর সুযোগ দেয়। এটিকে local OS authentication-এ সীমাবদ্ধ করুন এবং valid node checking লক করুন।
• সিকিউরিটিকে একবারের প্রজেক্ট হিসেবে দেখা। privilege সরে যায়, লোকজন চলে যায়, নতুন schema আসে। একটি পুনরাবৃত্ত রিভিউ ছাড়া, গত বছর যে ডেটাবেজ হার্ডেন করা হয়েছিল সেটা এই বছর আবার উন্মুক্ত। ক্যালেন্ডারে একটি ত্রৈমাসিক সিকিউরিটি রিভিউ রাখুন এবং এটিকে জরুরি অবস্থা নয়, বরং রুটিন রক্ষণাবেক্ষণ হিসেবে দেখুন।

এগুলোর একটিও পরিশীলিত আক্রমণ নয় — এগুলো housekeeping-এর ব্যর্থতা। ভালো খবর হলো, এগুলোর প্রতিটির সমাধান process, budget নয়।

শেষ কথা

একটি সত্যিকারের সুরক্ষিত ডেটাবেজ চালাতে যা যা দরকার তার সবই Oracle আপনাকে দেয় — ফাঁকটা প্রায় কখনোই প্রযুক্তি নয়, বরং control-গুলো আসলে চালু আছে কিনা, সঠিকভাবে কনফিগার করা আছে কিনা, এবং পর্যালোচনা করা হচ্ছে কিনা। least privilege দিয়ে শুরু করুন, কারণ এটা সবচেয়ে কম পরিশ্রমে সবচেয়ে বেশি ক্ষতি ঠেকায়। at rest ও in transit encryption যোগ করুন যাতে চুরি হওয়া ডেটা মূল্যহীন হয়। administration-কে data অ্যাক্সেস থেকে আলাদা করতে Database Vault, accountability-র জন্য Unified Auditing, আর পরিচিত ফাঁক বন্ধ করতে একটি ত্রৈমাসিক patch শৃঙ্খলা ব্যবহার করুন। এর কোনোটাই বিরল কিছু নয়; এর সবটুকুই "আমরা আশা করি আমরা সুরক্ষিত" আর "আমরা একজন auditor-কে তা প্রমাণ করতে পারি"-র মধ্যকার পার্থক্য। সিকিউরিটি এমন একটা posture যা আপনি বজায় রাখেন, এটা এমন কোনো প্রজেক্ট নয় যা আপনি শেষ করেন।