Oracle Database Security Assessment Tool (DBSAT)


Database Security Assessment tool / Veritabanı Güvenliği Değerlendirme Aracı (DBSAT), yaygın veritabanı güvenliği sorunlarını kontrol etmenize yardımcı olacak bir yardımcı program olarak Oracle tarafından sağlanmaktadır.
DBSAT ile, kısa vadeli güvenlik risklerini ortadan kaldırmak ve kapsamlı bir güvenlik stratejisi uygulamak için gerekli bulguları raporlayabilirsiniz. Oracle support’dan “Doc ID 2138254.1” dökümanı ile indirebiliriz.
DBSAT aracı üç modül içerir:

  • Collector : Erişim sağlanan sistemden , sql cümlecikleri ve işletim sistemi komutlarının çalıştırılması suretiyle veri toplar. Bunu öncelikle data dictionary viewlerı sorgulayarak yapar. Toplanan veri , DBSAT Reporter tarafından analiz aşamasında kullanılmak üzere bir JSON dosyaya yazılır.
  • Reporter  : Toplanan verileri analiz eder ve HTML, Excel, JSON veya txt formatlarından bir veritabanı güvenliği değerlendirme raporu oluşturur.
  • Discoverer : Mantıklı verileri bulmak ve raporlamak için kullanılan tek başına bir modüldür. Database Sensitive Data Assessment report / Veritabanına Duyarlı Veri Değerlendirme raporunu hazırlar.

Ayrıca DBSAT birkaç tamamlayıcı yardımcı program içerir (Reporter JSON çıkış formatı), bunlar:

  • DBSAT Extract – Bulguları kimlikleriyle çıkarmanızı sağlayan Python programı
  • DBSAT Diff – İki raporu karşılaştırmanıza ve farkları bulmanıza olanak sağlayan Python programı

Yukarıdaki DBSAT tamamlayıcı modüllerini, DBSAT aracını indirmek için kullandığınız aynı My Oracle Support dökümanından indirebilirsiniz [Doc ID 2138254.1]

DBSAT Kullanmak İçin Gereken Önşartlar

  • DBSAT’ın yalnızca aşağıdaki işletim sistemlerinde çalıştırılmak üzere onaylandığını unutmayın:
    • Solaris x64 and Solaris SPARC64
    • Linux x86-64
    • Windows x64
    • HP-UX IA (64-bit)
    • IBM AIX (64-bit) & Linux on zSeries (64-bit)
  • DBSAT aracını herhangi bir Oracle Database 10.2.0.5 veya sonraki sürümlerinde çalıştırabilir
  • Zip, unzip ve python yazılımının sunucuya kurulması gerekir. Aşağıdaki komutu vererek bunları kolayca yükleyebilirsiniz:
yum install -y zip unzip python

(devamı..)

14,217 total views, 30 views today


Network File System (NFS)

NFS  (Network  File  System),  1984  yılında  Sun  Microsystems  tarafından  geliştirilmişbir protokoldür. Uzaktaki makine üzerinde bulunan dosya sistem(lerin)i, farklı bir işletim sistemine  bağlayabilmeniz  (mount)  için  geliştirilmiştir.  Ve  bunu  yaparken,  kullanıcının sanki yerel bir dosya sistemi üzerindeymiş gibi çalışmasını sağlar.

TCP / IP’nin evriminin başlarında, kullanıcının ağ üzerinden başka bir makineye erişmesine izin vermek için bazı araçlar oluşturulmuştu. Telnet gibi remote access protocols (uzaktan erişim protolleri), kullanıcının başka bir bilgisayarda oturum açmasına ve buradaki kaynakları kullanmasına izin verdi. File Transfer Protocol  (FTP), birinin uzak bir makineden bir dosyayı kendi dosyasına kopyalamasına ve düzenlemesine izin verdi.

Ancak, bu çözümlerin hiçbiri, bir kullanıcının uzak bir makinedeki bir dosyaya, yerel bir dosyanın kullanıldığına benzer bir şekilde erişmesine izin verme kurallarına uymuyordu. Sun bu ihtiyacı karşılamak için Network File System (Ağ Dosya Sistemi)’i (NFS) yarattı. NFS, yerel ve uzak bir dosya arasındaki ayrımı ortadan kaldırmak amacıyla özel olarak tasarlanmıştır. Bir kullanıcı için, uygun kurulum yapıldıktan sonra, uzak bilgisayardaki bir dosya, kullanıcının yerel bilgisayarındaki bir sabit disk üzerindeymiş gibi kullanılabilir. Sun ayrıca, hem Sun tarafından hem de diğer şirketler tarafından yapılan donanımların birlikte çalışabilmesini sağlamak için NFS’yi özellikle satıcıdan/üreticiden bağımsız olacak şekilde üretti.

NFS, klasik TCP / IP client/server modelini izler. Bir sabit disk veya belirli bir bilgisayarın depolama aygıtındaki dizin, yönetici tarafından paylaşılan bir kaynak olarak ayarlanabilir. Bu kaynağa daha sonra paylaşılan sürücü(shared drive) veya directory denir ve client makinede yerel bir dizin gibi görünmesini sağlayarak bilgisayarlardan erişilebiliriz.

NFS, çalışmasını tanımlayan üç ana bileşen içeren bir mimari kullanır. External Data Representation (XDR) standardı, verilerin client ve server arasındaki değişimlerde nasıl temsil edildiğini tanımlar. Remote Procedure Call (RPC) protokolü, uzak makinelerde procedure çağırma yöntemi olarak kullanılır. Ardından, bir dizi NFS prosedürü ve işlemi çeşitli istekleri yerine getirmek için RPC kullanarak çalışır. Mount protokolü, kaynakları yukarıda belirtildiği gibi bağlamak için kullanılır.

NFS’nin en önemli tasarım hedeflerinden biri performanstı. Açıkçası, uzaktaki bir makineye yerelmiş gibi bir dosya ayarlasanız bile, gerçek okuma ve yazma işlemleri bir ağ üzerinde ilerlemek zorunda. Genellikle bu sadece bir bilgisayar içerisine veri göndermekten daha fazla zaman alır, bu yüzden protokolün kendisinin mümkün olduğunca “yalın ve ortalama” olması gerekiyordu. Bu karar, çoğu dosya aktarım protokolünün yaptığı gibi güvenilir TCP yerine TCP / IP’de aktarım için güvenilir olmayan User Datagram Protocol’nün (UDP) kullanılması gibi bazı ilginç kararlara yol açmıştır. Bu da protokolün bir bütün olarak nasıl çalıştığı üzerinde ilginç sonuçlara sahiptir.

NFS için bir diğer önemli tasarım amacı basitti (elbette performansla ilgili). NFS sunucularının durumsuz olduğu söyleniyor, bu protokolün hangi sunucuların hangi clientler tarafından hangi dosyaların açıldığını takip etmesine gerek kalmayacak şekilde tasarlandığı anlamına geliyor. Bu, isteklerin birbirinden bağımsız olarak yapılmasına izin verir ve bir sunucunun karmaşık kurtarma prosedürlerine ihtiyaç duymadan çökmeler gibi olaylarla incelikle başa çıkmasını sağlar. Protokol ayrıca, isteklerin kaybolması veya çoğaltılması durumunda dosya bozulması yaşanmayacak şekilde tasarlanmıştır.
(devamı..)

1,618 total views, no views today


systemctl

systemd, Linux için bir sistem ve servis yöneticisidir ve SystemV ve Upstart’ın yerini almaktadır. systemd, servis yapılandırmasını ve davranışını Linux dağıtımları arasında birleştirmeyi amaçlar.
Systemd’nin amacı; bilgisayardaki sistem ve servislerin çalışmasını organize etmektir. Yani modern linux işletim sisteminde başlama (startup) ve sunucu (server) proseslerini yöneten sistem olarak systemd sistem kaynaklarının, arkaplan (daemon) ve diğer süreçlerin (process) etkinleştirilmesi için bir mekanizma sağlar. Bu yönetimi, systemctl, journalctl, notify, analyze, cgls, cgtop, loginctl ve nspawn olarak adlandırılan araçlar sayesinde gerçekleştirir.

Arkaplan süreçleri (daemons) adından da anlaşılabileceği gibi başlatıldıklarında görevlerini yürütmek üzere arka planda bekler veya çalışırlar. Bu süreçler tipik olarak işletim sistemi yüklenirken (boot) başlatılırlar ve sistem kapatılana ya da manuel olarak durdurulana kadar arkaplanda (background) çalışmayı sürdürürler. Genel bir ilke olarak arkaplan süreç adları genellikle d harfi ile sonlanır (sshd – ssd deamon gibi).

Systemd ortamında aşağıdaki kavramlar yaygın olarak kullanılır:
• Daemon: başlatıldıklarında görevlerini yürütmek üzere arka planda bekleyen veya çalışan süreçler.
• Socket: Bağlantıları dinlemek için arkaplan süreçleri tarafından kullanılır. Yerel ve uzak istemciler için ana iletişim kanalıdır. Süreçler tarafından yaratılırlar.
• Service: Genellikle bir ya da daha çok sayıda arkapan sürecine işaret eder Servisi başlatma/durdurma işlemi genellikle sistem durumunda (state) kalıcı bir değişikliğe neden olur.

Eskiden init dediğmiz ve işletim sistemi kernel yüklemesinden sonra çalışan ve PID (Process ID) 1 olan süreçlerle yönetilmekte idi. Çekirdek kendini başlattığı (belleğe yüklendiği, çalışmaya başladığı ve aygıt dosyaları, veri yapıları ve benzeri şeyleri başlattığı zaman) ve kullanıcı seviyeli bir program olan initsürecini başlattığında, kendi üstüne düşen açılış işlemlerini bitirmiş olur. Bundan dolayı init her zaman için ilk süreçtir ve süreç numarası da daima 1’dir. init süreci /etc/inittab dosyasını okuyup sistemin hangi Run Level’dan başlayacağına karar verirdi. Aşağıda /etc/inittab dosyasından bir kesit sunulmaktadır.

# Default runlevel. The runlevels used by RHS are:
# 0 – halt (Do NOT set initdefault to this)
# 1 – Single user mode
# 2 – Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 – Full multiuser mode
# 4 – unused
# 5 – X11
# 6 – reboot (Do NOT set initdefault to this)
#
id:3:initdefault:

Buradaki id:3:initdefault: satırı bizim işletim sistemimizin RunLevel 3 ‘den başlayacağını göstermektedir. Red Hat sistemlerde RunLevel’lar

• 0 – halt (Sistemi kapatmak –poweroff veya halt- için kullanılan runlevel)
• 1 – Single user mode (Sistemi kurtarmak için kullanılan ve network ayarlarının aktive edilmediği tekli kullanıcı mode’u. Bazı yerlerde S veya s olarak da adlandırılır.
• 2 – Multiuser NFS olmadan çoklu kullanıcı mode’u (Bu runlevel 3. Runlevel ile genel olarak aynıdır. Tek fark network ayarlarını içermemesidir.)
• 3 – multiuser mode (Network ayarlarını nda aktive edildiği ve genellikle kullanılan RunLevel’dır.
• 4 – kullanılmıyor.
• 5 – X11 (Runlevel 3 e ek olarak görsel ekranın- ki biz buna X veya X11 de deriz- da başlatıldığı runlevel. Runlevel 3’den sonra en çok tercih edilen runlevel’dır.)
• 6 – reboot (Sistemin kapatılıp tekrar açıldığında kullanılan RunLevel’dır.

İnit süreci ön tanımlı runlevel’ı ayarladıktan sonra sistemde /etc/rc.d/init.d/ altında bulunan ve rpm paketleri içinde gelen servis scriptlerini (bunlar bir shell scripttir!) çalıştırır. Örnek olarak eğer runlevel 3 de isek ve sshd servisi çalışacaksa bunun başlangıç scripti /etc/rc.d/init.d/sshdaltında yer almakta. Bunun runlevel 3 de çalışmasını da /etc/rc.d/rc3.d/S55sshd scripti sağlamakta idi. Buradaki S harfi bunun start edilleceği, 55 ise başlangıç sırasını belirtmektedir.

# ls -la /etc/rc.d/rc3.d/S55sshd lrwxrwxrwx 1 root root 14 Jun  6  2011 /etc/rc.d/rc3.d/S55sshd -> ../init.d/sshd

(devamı..)

983 total views, no views today



Veritabanında Denetleme (Audit)

Veritabanında standart denetleme audit_trail parametresine değer (os, db, db extended, xml, xml extended) atanması ile başlar. Eğer denetlemeyi durdurmak istersek parametre NONE yapılmalıdır. Bu parametrenin none yapılması ile beraber veritabanı kapatılıp açıldığında tüm denetleme durmuş olur.

Denetlemeler komut, yetki, obje ve network aktiviteleri bazında tanımlanır. Denetleme başlatmak için AUDIT, durdurmak için NOAUDIT komutu kullanılmalıdır.

Bir kullanıcı kendine ait tüm kullanıcılar üzerinde AUDIT başlatabilir. Başka kullanıcıların objeleri üzerinde AUDIT başlatmak için ise AUDIT ANY yetkisi olmalıdır. Sistem yetkileri üzerinde AUDIT tanımlamak için AUDIT SYSTEM yetkisi olmalıdır. NOAUDIT komutunun çalıştırılması için ise özel bir yetkiye gerek yoktur.

O7_DICTIONARY_ACCESSIBILITY parametresi FALSE ise denetim izleri yalnızca SYSDBA yekili kullanıcılar tarafında silinebilir. DELETE ANY TABLE yetkisine sahip kullanıcılar dahi silemezler.

Tüm denetim kayıtları herhangi bir transaction’ın tanımlanmasını beklemeden, denetlenecek komutun çalışma anında yazılır.

Komutların Denetlenmesi

Komut bazında denetleme yapılması, kullancıların çalıştırdığı,

  • DML(INSERT, UPDATE, DELETE, SELECT)
  • DDL(CREATE, DROP….)

gibi veritabanı komutlarının denetlenmesi işlemidir. Denetleme yaparken denetleyeceğimiz obje türünü girmemiz yeterlidir. AUDIT komutunda yazdığınız obje türüne türüne göre istenilen komutlar denetlenir. Obje türüne göre denetleyebileceğimiz komutlar aşağıdaki gibidir.

Oracle Audit System

 

 

 

 

 

 

 

Bu tür komut bazlı denetlemeyi başlatmak için AUDIT SYSTEM yetkisine sahip olunması gerekir. (dba_sys_privs viewi sorgulanarak yetki sahipleri bulunabilir) Komut bazında denetleme yeni session açıldığında aktif olur.

Örneğin tablo objesi DELETE komutunun tüm veritabanında denetlenmesi için aşağıdaki komutu çalıştırabiliriz.

audit delete table by access;

Yada sadece SYSTEM kullanıcısında çalıştırılan SELECT TABLE komutunu denetlemek istersek aşağıdaki komutu çalıştırabiliriz.

audit select table by system;

Verilen audit leri görmek için DBA_STMT_AUDIT_OPTS viewini sorgulayabiliriz.

Oracle Audit Privilege

 

 

Yukarıdaki resimdede görüldüğü gibi;

  • SYSTEM kullanıcısında çalışan tüm SELECT TABLE komutları
  • SYSTEM kullanıcısının çalıştırdığı tüm komutların
  • EXEMPT ACCESS POLICY yetkisini veren GRANT komutlarının
  • Bütün kullanıcılarda olmak üzere DELETE TABLE komutlarının denetlendiğini görmekteyiz.

(devamı..)

6,551 total views, 3 views today


Oracle Audit – Denetim İzlerinin Yönetilmesi

Denetim izleri yapılan konfigürasyona göre veritabanında tablo olarak veya işletim sisteminde dosya olarak tutulmaktadır. Bu denetim izlerini silmek veya başka ortamlara taşımak için farklı yöntemler kullanılabilir. Fakar Oracle 11g ile beraber denetim izlerinin yönetilmesi için DBMS_AUDIT_MGMT paketi kullanılmaya başlanmıştır. Böylece değişik ortamlarda tutulan denetim izleri tek bir paket ile yönetilebilir hale gelmiştir. DBMS_AUDIT_MGMT paketi denetim izleri üzerinde taşıma silme işlemi yaparken veritabanındaki sessionları bekler duruma getirmez ve kullanıcılar çalışmalarına kesintisiz devam ederler. Bu nedenle değişik yöntemler ile denetim izlerini yönetebilmemize rağmen(Örneğin tabloda ise DELETE komutu, işletim sisteminde ise rm komutu kullanabiliriz) DBMS_AUDIT_MGMTpaketini kullanmak daha doğrudur.

Veritabanında Saklanılan Denetim İzlerinin Farklı Tablespacelere Taşınması

Veritabanında tutulan standart denetim izleri SYS.AUD$ tablosunda, ayrıntılı denetim izleride(Fine Grained Auditing-log mekanizması diyebiliriz) FGA_LOG$ tablolarında tutulur. Veritabanı ilk yaratıldığında bu tablolar varsayılan olarak SYSTEM tablespace’inde tutulur. Ama tabloların büyümesi ve denetleme politikası nedeniyle SYSTEM tablespace üzerinde baskı oluşabilir. Bu nedenle sık sık silinmesi ve sürekli ekleme yapılan tabloları ayrı bir tablespace’e taşımak isteriz.

Bu işlem DBMS_AUDIT_MGMT.set_audit_trail_location veritabanı paketi ile yapılır. Bu paket 2 tane parametre alır. Bir tanesi taşımak istediğiniz tablo türünü gösteren parametre, diğeri ise tabloların taşınacağı tablespace adıdır.

Tablo türünü gösteren parametre aşağıdaki 3 değerden birini alır.

  • DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: Standard denetim izi (AUD$).
  • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: Ayrıntılı enetim izi (FGA_LOG$).
  • DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD : Standart ve Ayrıntılı denetim izi için.
SELECT table_name, tablespace_name
FROM dba_tables
WHERE table_name IN ('AUD$', 'FGA_LOG$')
ORDER BY table_name;
TABLE_NAME   TABLESPACE_NAME
------------------------------ ------------------------------
AUD$            SYSTEM
FGA_LOG$        SYSTEM

CREATE TABLESPACE AUDIT_TS
DATAFILE
'/u01/app/oracle/oradata/ORCL/AUDIT_TS' SIZE 104857600 AUTOEXTEND ON NEXT 10485760 MAXSIZE UNLIMITED;


BEGIN
DBMS_AUDIT_MGMT.set_audit_trail_location(
audit_trail_type = DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
audit_trail_location_value = 'AUDIT_TS');
END;
/


SELECT table_name, tablespace_name
FROM dba_tables
WHERE table_name IN ('AUD$', 'FGA_LOG$')
ORDER BY table_name;
TABLE_NAME   TABLESPACE_NAME
------------------------------ ------------------------------
AUD$           AUDIT_TS
FGA_LOG$       SYSTEM


BEGIN
DBMS_AUDIT_MGMT.set_audit_trail_location(
audit_trail_type = DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD,
audit_trail_location_value = 'AUDIT_TS');
END;
/


SELECT table_name, tablespace_name
FROM dba_tables
WHERE table_name IN ('AUD$', 'FGA_LOG$')
ORDER BY table_name;

TABLE_NAME  TABLESPACE_NAME
------------------------------ ------------------------------
AUD$         AUDIT_TS
FGA_LOG$     AUDIT_TS

(devamı..)

3,640 total views, no views today


  • Sertifikasyon



  • Etiketler

  • Topluluklar

                     
                     
  • Copyright © 1996-2010 Mustafa Bektaş Tepe. All rights reserved.
    Türkçeleştirme Blogizma | AltyapıWordPress
    Takip Et

    Her yeni yazı için posta kutunuza gönderim alın.

    Diğer takipçilere katılın: