BigDataSecurity

Izvor: SIS Wiki

Skoči na: orijentacija, traži

--Ivan Majnaric 16:59, 20. siječnja 2017. (CET)

Sadržaj

Cassandra + Spark security

Datastax Cassandra

Cassandra je distribuirani sustav baza podataka kojoj je glavna uloga upravljanje sa velikom količinom strukturiranih podataka na više servera te pritom pružanje visoko dostupne usluge bez postojanja dijela sustava gdje može doći do onesposobljavanja cijelog sustava. Ujedno u navedenoj definiciji se može doći do odgovora zašto je upravo ovaj tip baza podataka odabran kao najbolji primjer distribuirane baze podataka. Samo neke od prednosti po kojima se Cassandra kao sustav baza podataka ističe su:

Kontinuirana dostupnost
Linearno skaliranje performansi
Jednostavno izvršavanje operacija
Jednostavna distribucija podataka preko više podatkovnih centara
Zone dostupnosti u obliku oblaka (end. Cloud)

Upravo zato što je Cassandrina arhitektura složena na netradicionalan način odnosno ne u gospodar-rob (eng. Master-slave ) konfiguraciji već u konfiguraciji bez glavnog čvora nazvanoj „prsten“ razlog je u kojem se kriju sposobnosti gdje se omogućava skaliranje, djelovanje te kontinuirani odnosno neprekidni rad. Konfiguracija u obliku „prstena“ je ta koja Cassandri daje dodatnu eleganciju te jednostavnost u radu. Kod takvog tipa konfiguracije distribuirane baze podataka, svaki čvor sustava ima identičnu ulogu gdje svaki komunicira sa svim čvorovima sustava na jednaki način.

Cassandrina arhitektura još se zove i „građena za skaliranje“ što znači da je u mogućnosti jednostavno rukovati sa ogromnim količinama podataka te tisućama korisnika i operacija istovremeno čak i preko više podatkovnih centara u istoj mjeri koliko i sa malom količinom podataka. Kao pravi pokazatelj koliko se zapravo Cassandra u stvarnosti koristi primjer su velike organizacije koje su je izabrale kao temelj gradnje njihovih sustava, a to su: Apple, eBay, Spotify, Über te slični. (Planet Cassandra 2015)

Apache Spark

Apache Spark je besplatan okivir za procesuiranje podataka u klasteru. Alat zamjenjuje Hadoop kao glavni sustav za obradu velikih količina podataka. Spark se kao takav može koristiti za batch te za realtim obradu podataka. Jedinstvena je platforma za razičit evrste algoritama te se najčešće koristi uz programske jezike kao Scala te Python. Važno je napomenuti da je Spark pisan u Scali no isto tako uz Python podržava i Javu. Podatke koji se procesuiraju obično nije potrebno spremati kao međupodatke na disk te se isti drže u memoriji što doprinosi na brzini, čak i do 100 puta većoj od sustava kao Hadoop-ov M/R. Ono po čemu je jedinstven je to što se distribuirani podaci pišu na slučan način kao i lokalni.

U seminaru koji slijedi bit će objašnjena sigurnost Cassandrinog te Sparkovog klastera od četiri node-a. Postoje dvije mogućnosti konfiguracije sigurnosti to su pomoću lozinke te LDAP autentifikacije te pomoću Keberosa. Oba načina autentifikacijiskih mehanizama odnose se na na povezivanje Sparka za Cassandrom ne i autentifikacije Sparkovih komponenti između sebe. Isto tako, postoji i klijent-čvor enkripcija preko SSL-a za sve konekcije od Spark do Cassandre. Cijela Spark komunikacija nije enrkptirana te za isto ne postoji podrška od strane Sparka.

Pristupanje Cassandri preko Sparka

U nastavku možete vidjeti kako se preko jednostavnog programa u Sparku moguće spojiti na Cassandru na određenom hostu te pristupiti nekim podacima kroz određeno korisničko ime te lozinku.

U IntelliJ-u smo kreirali novi Scalin projekt u obliku SBT-a te smo kao dependecije stavili sljedeće:

 name := "cassandra-spark"
  
 version := "1.0"
  
 scalaVersion in ThisBuild := "2.11.8"
 val sparkVersion = "2.0.2"
  
 resolvers in Global ++= Seq(
   "Sbt plugins"                   at "https://dl.bintray.com/sbt/sbt-plugin-releases",
   "Maven Central Server"          at "http://repo1.maven.org/maven2",
   "TypeSafe Repository Releases"  at "http://repo.typesafe.com/typesafe/releases/",
   "TypeSafe Repository Snapshots" at "http://repo.typesafe.com/typesafe/snapshots/"
 )
   
 libraryDependencies ++= Seq(
   "org.apache.spark" %% "spark-core" % sparkVersion,
   "org.apache.spark" %% "spark-sql" % sparkVersion,
   "org.apache.spark" %% "spark-streaming" % sparkVersion,
   /*Kafka -0-8 by documentation: http://spark.apache.org/docs/latest/streaming-kafka-integration.html
   is for Broker version: 0.8.2.1 andd higher, -0-10 for .0.10. and higher*/
   "org.apache.spark" %% "spark-streaming-kafka-0-8" % sparkVersion,
   "com.datastax.spark" %% "spark-cassandra-connector" % "2.0.0-M3"   
 )

Te smo pomoću sljedećeg koda pristupili Cassandrinom keyspaceu te podacima:

  /**
 * Created by biadmin on 12/01/2017.
 */
  
  import org.apache.spark.{SparkConf, SparkContext}
  import com.datastax.spark.connector._
  
  object clusterPointer {
   def main(args: Array[String]): Unit = {
     val conf = new SparkConf()
       .set("spark.cassandra.connection.host","server_ip")
       .set("spark.cassandra.auth.username", "cassandra")
       .set("spark.cassandra.auth.password", "cassandra")
       .setMaster("local[*]")
       .setAppName("clusterPointer")
     
     val sc = new SparkContext(conf)
     val rdd  = sc.cassandraTable("demo", "orders")
        
     rdd.foreach(println)
    
    }
  }

Konačna slika ispisa podataka je sljedeća:

Kerberos autentifikacija

Kerberos autentifikacija oslanja se na konekciju Sparka na Cassandru te kao što je već navedeno u prethodnom primjeru ne i autetentifikaciju Spark komponenti izemđu sebe. Sparkov web sučelje je osigurano te je moguće prikazati Sparkovu konfiguraciju uključujući i delegacijski token kada se koristi Kerberos.

SSL

Klijent-čvor enkripcija štiti za vrijeme spajanja Sparkovog izvršitelja sa Cassandrom podatke u prijenosu na način da uspostavlja siguran kanal između klijenta te čvora kao koordinatora. SSL je u potpunosti distribuiran te ne zahtijeva dodatno namještanje dijeljenog autentifikacijskog servisa. Ono što je potrebno je u početku prirpemiti serverske akreditive te dopustiti klijent-čvor SSL.

Kreirati novi file ./cassandra/cqlshrc te unesti

  [authentication]
  username = sis
  password = sis
  
  [connection]
  hostname = server_ip
  port = 9042
  
  [ssl]
  certfile = ~/keys/cassandra.cert
  validate = true ## opcionalno, true po defaultu
  
  [certfiles]  ## Opcionalna sekcija, prebrisuje defualte certifikate u [ssl] sekciji 
  192.168.1.3 = ~/keys/cassandra01.cert
  192.168.1.4 = ~/keys/cassandra02.cert

Pripremanje serverskih certifikata

Svi čvorovi moraju imati sve relevantne SSL certifikate. Baza ključeva (eng. Keystore) sadrži sve privatne ključeve dok eng. Truststore sprema sve SSL certifikate od neke treće strane. Za svaki čvor te na zahtijeva prijavljivanje pouzdanog i prepoznatnog javnog autorativnog certifikata. Kako bi pripremili serverske certifikate potrebno je:

Generirati par privatnog i javngo ključa sva svaki čvor klastera na način da se ključna lozinka (eng. Key password) ostavi jednaka kao i lozinka baze ključeva:
1. $ keytool –genkey –alias hdp0 –keyalg RSA –keystore .keystore
  1. Nakon što se otvori prozor kao „What is your first and last name“, potrebno je unesti ime domene Cassandrinog čvora na kojem se generiraju ključevi. Te iste vrijednosti bit će korištene za postavljanje certifikata CN koji se koristi za serversku autentifikaciju klijenta.
Ponoviti isti postupak za svaki čvor.
Eksportati javni dio certifikata u odvojenu datoteku te kopirati te iste cerfitikate na sve ostale čvorove.
1. $ keytool –export –alias hdp0 –file hdp0.cer –keystore .keystore
Dodati certifikate svakom truststore-u svakog čvora kako bi čvorovi koli provjeriti identitete jedni drugih.
1. $ keytool –import –v –tustcacerts –alias server_ip –file hdp0.cer –keystore .truststore
2. $ keytool –import –v –tustcacerts –alias other_server_ip –file hdp1.cer –keystore .truststore
3. $ keytool –import –v –tustcacerts –alias other_server_ip –file hdp2.cer –keystore .truststore
4. $ keytool –import –v –tustcacerts –alias other_server_ip –file hdp3.cer –keystore .truststore
Na koncu se pobrinuti da je .keystore vidljiva samo korisniku koji koristi iste ne i svim ostalim korisnicima sustava.

Unutrašnja autorizacija Cassandrinog klastera

LDAP je skraćenica od eng. Lightweifght Directory Access Protocol te isti služi kao standardni način autentifikacije korisnika kroz aplikacije. Kada se LDAP autentifikacija omoguće korisnici koji su dirikirani vanjskim LDAP serverom mogu biti autentificirani. Svaki autentificirani korisnik tada može biti autoriziran tako da bude u mogućnosti pristupanja Cassandrinim objektima ( GRANT/REVOKE metode autorizacije).

Procedura je sljedeća:

Potrebno je naći Cassandrinu datoteku conf te unutar nje datoteku imena cassandra.yaml. Ukoliko je Cassandra instalirana kao paket tada se nalazi u /etc/cassandra/ te nakon što se nađe datoteka potrebno je authenticator postaviti na:

    Authenticator: PasswordAuthenticator

PasswordAuthenticator označava kako je potreban par korisničko ime/lozinka ua authentifikaciju korisnika. Sadržava korisnička imena zajedno sa heširanim lozinkama u sys_auth.credentials tablici. Ukoliko koristi autentifikator tada je poželjno da se replikacijski faktor sheme imena system_auth poveća. Replikacijski faktor u našem slučaju je 2. Isto tako nakon promjene autentifikatora, poželjno je promijeniti i autorizatora.

   Autorizer': CassandraAuthorizer

CassandraAuthorizer sprema sve pristupe i ograničenje u system_auth.permissions tablici. Isto tako je poželjno da se poveća replikacijski faktor iste. Sada kada je autentifikacija omogućena te ukoliko pokušamo pristupiti bilo kojoj shemi Cassandra će vratiti grešku. Po zadanom, Cassandra pruža super korisnički računa sa korisničkim imenom cassandra te lozinkom cassandra. Prijavom u Cassandru sa takvim korisničkim imenom dobivaju se sve moguće ovlasti nad klijentom i podacima čvora. Pokušamo li se prijaviti sa drukčijim korisničkim računom dobit ćemo sljedeće:

Pokušamo li sa korisničkim superuserom cassandra te passwordom cassandra dobiti ćemo:

Kreiranje novih korisnika

Novog korisnika kreiramo u CQLSH-u, odnosno Cassandra Query Language Shell. Nakon što smo kreirali novog korisnika kao superuser-a sis, sis_no kao običnog korisnika te oduzimamo pomoću naredbe revoke sve ovlasti korisnika cassandra pošto je to defaultni user te kako bi se obranili od mogućeg nagađanja korisnika i šifre.

Dodjeljivanje/oduzimanje prava

Kako smo napravili korisnika sis_no provjerit ćemo samo funkcioniranje predavanja ovlasti nad keyspaceom Cassandrinog klastera. Kako u klasteru postoji keyspace naziva nth, korisniku sis_no oduzet ćemo sva prava nad istim te pokušati pristupiti tom istom keyspaceu.

Konfiguracija multi-čvor sustava (iptables)

$ sudo yum update

$ sudo yum install iptables-services -y

Tokom izvršavanja instalacije potrebno je za sva pravila napisati „yes“. U nastavku će se ispravljati već postavljene postavke. Naredba iptables podržava samo IPv4 promet. Ukoliko je prisutan i IPv6 promet tada je potrebno koristiti naredbu ip6tables. Kako bi implementirali vatrozid prvo ćemo ispraviti pravila koja se nalaze na

$ sudo nano /etc/sysconfig/iptables .

Potrebno je cijeli sadržaj datoteke izmijeniti sa:

   
   //filter
   / Dopusti sve izlazno, no dropaj ili odbij sav promet koji dolazi ili se prosljeđuje po defaultu

   :INPUT DROP [0:0] 
   :FORWARD DROP [0:0]
   :OUTPUT ACCEPT [0:0]

   / Chanovi ili lanci
   :UDP - [0:0]
   :TCP - [0:0]
   :ICMP - [0:0]

   / Prihvaljivi TCP promet
   -A TCP -p tcp --dport 22 -j ACCEPT
   / Acceptable ICMP traffic

   / Predložena pravila
   -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
   -A INPUT -i lo -j ACCEPT

   / Odbiti nevaljate pakete
   -A INPUT -m conntrack --ctstate INVALID -j DROP
   / Propustiti promet do specificiranog protokol lanca
   // Dopuštanje samo novih konekcija (uspostavljene ili povezane konekcije trebale bi biti već handlane)
   // Za TCP, dopusti dodatno samo SYN pakete koji su valjani
   // metoda za dopuštanje novih konekcija
   -A INPUT -p udp -m conntrack --ctstate NEW -j UDP
   -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP
   -A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP

   // Odbiti sve što je do sada došlo do tu
   // Protocol-specific w/ poruka odbitka
   -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
   -A INPUT -p tcp -j REJECT --reject-with tcp-reset
   -A INPUT -j REJECT --reject-with icmp-proto-unreachable

   // Commit the changes
   COMMIT

   //raw
   :PREROUTING ACCEPT [0:0]
   :OUTPUT ACCEPT [0:0]
   COMMIT

  //nat
  :PREROUTING ACCEPT [0:0]
  :INPUT ACCEPT [0:0]
  :OUTPUT ACCEPT [0:0]
  :POSTROUTING ACCEPT [0:0]
  COMMIT

  //security
  :INPUT ACCEPT [0:0]
  :FORWARD ACCEPT [0:0]
  :OUTPUT ACCEPT [0:0]
  COMMIT

  //mangle
  :PREROUTING ACCEPT [0:0]
  :INPUT ACCEPT [0:0]
  :FORWARD ACCEPT [0:0]
  :OUTPUT ACCEPT [0:0]
  :POSTROUTING ACCEPT [0:0]
  COMMIT

Napisana pravila prihvaćamo sljedećom naredbom:

$ sudo service iptables-persistent reload

Načinom koji je gore prikazan namješten je lanac koji će prcesuirati sve pakete koji su namijenjeni našem serveru. Isto tako omogućili smo cijelo odlazni promet te onemogućili sve pakete koji se prosljeđuju u slučaju da naš server posluži kao router za ostale hostove. U osnovi, pravila koja postavljaju vatrozid onemogućit će sav dolazni promet do zadanom. Ono što je sljedeće potrebno napraviti su iznimke za ostale servise te promet koji želimo isključiti iz ovih setova pravila. U glavnom INPUT lancu dodali smo općenita generička pravila za promet za kojeg pouzdano znamo da će svaki put jednako biti obrađen na isti način. Primjer toga su odbijeni paketi koji se smatraju „nevaljanim“ te promet koji uvijek želim propuštati na temelju konekcije koja je već uspostavljena.

Nadalje, u ovom primjeru jedini servisi koje mi dopuštamo su SSL u našem TCP lancu. Svaki promet koji nije u skladu sa generičkim ili pravilima servisa u lancu specificanog protokola bit će rukovan od starane TCP lanca. Isto tako postavili smo i defaultna pravila za DROP koji će odbijati pakete koji uspiju proći kroz postavljena pravila. Pravila koja se nalaze na kraju INPUT lanca odbit će sve pakete te će poslati povratnu informaciju klijentima na način da će oponašati način rada servera kao da se ne vrti niti jedan servis na tom portu.

Kako bi mogli nastaviti danju implementaciju vatrozida pomoću naredbe iptables potrebno je resetiranje vatrozida:

$ sudo service iptables flush

Upisivanjem naredbe:

$ sudo iptables –S

Moguće je vidjeti da su pravila u tablici filtara nestala te da je defaultna pravila porstavljena na ACCEPT na svim lancima:

    Output
    -p INPUT ACCPET
    -p FORWARD ACCEPT
    -p OUTPUT ACCEPT

Kreiranje eng. Protocol specific lanca

Postavljanjem istih kreiraju se pravila gdje se izgrađuju iznimke za pravila koja odbijaju servise koje želimo izložiti. Kreirat ćemo po jedno pravilo za UDP promet, TCP te jedan sa ICMP promet.

$ sudo iptables -N UDP

$ sudo iptables -N TCP

$ sudo iptables -N ICMP

Možemo napraviti i korak unaprijed te napraviti iznimku za SSH promet. Pošto SSH koristi TCP dodat ćemo pravilo koje prihvaća TCP promet prema odredišnom portu 22 na TCP lanac:

$ sudo iptables -A TCP -p tcp --dport 22 -j ACCEPT

U INPUT lancu, gdje započinje filtirranje cjelokupnog dolaznog prometa, moramo dodati pravila opće namjene. Ta ista pravila služe za prihvaćanje prometa niskog rizika(lokalni promet i promet koji čija je konekcija već prihvaćena i provjerena) te neprihvaćanje prometa koji nema smisla tj. nepravilnih paketa. Sukladno tome napravit ćemo iznimku za sav rpromet koji je dio već uspostavljene konekcije ili je povezan sa istom:

$ sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Navedena naredba koristi conntrack ekstenziju koja pruža unutarnje praćenje tako da iptables posjeduju kontekst potreban za procijenu paketa kao dijela veće konekcije umjesto da gleda kao na tok nepovezanih paketa. Isto tako poželjno je propustiti lokalni promet koji je generiran od strane servera te je predodređen za isti server. Obično je to tip prometa kojeg genriraju servisi na nekom hostu kako bi komunicirali jedni sa drugima.

$ sudo iptables -A INPUT -i lo -j ACCEPT

Već je bilo govora od odbijanju svih nepravilnih paketa. Paket može biti nepravilan na nekoliko načina. Može biti nepravilan na način da se referencira na konekciju koja ne postoji, mogu biti predodređeni za sučelja, adrese ili portove koji ne postoje ili jednostavno deformirani. U svakom slučaju mi ćemo odbiti bilo kakav nepravilan paket pošto ne postoji neki pravilan način za rukovanje sa istim te upravo radi toga mogu reprezentirati malicioznu radnju:

$ sudo iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

Ako napravimo sumu do sada svega što smo napravili možemo vidjeti kako smo uspostavili generalna pravila za INPUT lanac te neka specifična pravila za određene servise u našem „protocol-specific“ lancu. Trenutno sav promet koji primimo prolazi kroz INPUT lanac te ne postoji put dolaska do „protocol-specific“ lanca. Ono što ćemo u nastavku napraviti je usmjeravanja prometa sa INPUT lanca na prikladan protocol-specific lanac. Isto tako osigurat ćemo da paketi predstavljaju novu konekciju jer svaka već uspostavljena konekcija bi trebala biti ve izrukovana ranije. Za TCP pakete dodat ćemo dodatni zahtjev da paket mora bit SYN tipa tj. tip kao takav će biti jedini validni kako bi TCP konekcija mogla biti uspostavljena:

$ sudo iptables -A INPUT -p udp -m conntrack --ctstate NEW -j UDP

$ sudo iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP

$ sudo iptables -A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP

Nadalje, odbacit ćemo sav preostali promet. Ukoliko paket koji je proslijeđen „protocol-specfic“ lancu ne odgovara niti jednom pravilu istog, kontrola će isti vratiti na INPUT lanac. Bilo što da dođe do takve točke ne bi trebalo biti dopušteno sa vatrozidom koji trenutno gradimo. Kako bi odbacili takve pakete koristit ćemo opciju REJECT koja šalje poruke kao odgovore klijentima. To nam omogućava da specificiramo odlazne poruke kako bi mogli oponašati odgovor koji će biti poslan klijentu ukoliko pokuša poslati pkaete na regularan zatvoreni port. Ukoliko klijent pokuša doći do zatvorenog UDP porta odgovor će rezultirati sa ICMP porukom o nedostupnosti porta. To isto možemo imitirati upisujući sljedeće:

$ sudo iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable

Ukoliko pokuša uspostaviti TCP konekciju nekog zatvorenog porta kao dogovor dobit će TCP RST odgovor te to isto rješavamo sljedećom linijom:

$ sudo iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset

Za sve ostale pakete možemo slati ICMP poruku o nedostupnosti protokola koja će označavati da server ne reagira na pakete tipa kao takvog:

$ sudo iptables -A INPUT -j REJECT --reject-with icmp-proto-unreachable

Zadnja tri pravila koja ćemo dodati trebala bi rukovati sa ostatkom prometa INPUT lanca. Kao zmjeru predostrožnosti trebali bi postaviti zadanu policu pravila na DROP. Isto tako, tu istu policu trebali bi postaviti u FORWARD lanac ukoliko servr nije konfiguriran kao router za ostale strojeve:

$ sudo iptables -P INPUT DROP

$ sudo iptables -P FORWARD DROP

$ sudo iptables save

Nakon što smo postavili vatrozid, namjestili Cassandrine servere potrebno je dodati dodatna pravila za Cassandrine portove, tj. potrebno je modificirati pravila vatrozida za IPv4.

$ sudo nano /etc/sysconfig/iptables

Sljedećom linijom ćemo omogućiti propuštanje prometa na bitnim Cassandrinim pirtovima. Liniji ispod „# Reject anything that's fallen through to this point“ potrebno je zalijepiti slijedeći dio pravila:

    -A INPUT -p tcp -s your_server_ip,your_other_server_ip,your_other_server_ip -m multiport --dports 7000,9042 -m state --state NEW,ESTABLISHED -j ACCEPT

Nakon što smo isto napravili potrebno je resetirati servis IPTables-a te smo samim tim osigurali ponašanje servera i paketa koji pristižu.

$ sudo service iptables-persistent restart

Primjer pristupanja jednom od čvorova nakon što je postavljen iptables

Primjer pristupanja preko dozvoljnog porta -9042

Data auditing

Pregled podataka ili eng. data auditing implementirana je na log4j baziranoj integraciji. Način na koji Cassandra sprema pregled podataka je tako što ga sprema u direktorij koji je naznačen u dokuementu log4j.property. Dokument za pregled informacija zapravo sprema sve informacije o određenom čvoru gdje je takav pregled omogućen. Na primjer, ukoliko je na hdp1.local čvoru pregled omogućen, a na hdp2.local nije. Ažuriranje sustava na hdp2.local te bilo kakvo izvšavanje naredbi na istom neće se generalno pokazati i kod pregleda log-ova na hdp1.local. Kako bi dobili maksimalan raspon informacija o pregledu podataka poželjeno je omogućiti to isto na svakom čvoru. Provjera je konfigurirana kroz tekstualno datoteku u datotečnom sustavu stoga je ta ista ranjiva na temelju sigurnosti operacijskog sustava. Poželjno je tu istu datoteku spremiti enkriptiranu na razini operacijskog sustava korištenjem Vormetric ili na primjer, osigurati je.

Konfiguracija pregleda podataka

Procedura konfiguracije istog je sljedeća:

1. Otvoriti log4j-server.properties dokument u sljedećem direktoriju:

   $ nano /resources/cassandra/conf

2. Kako bi konfigurirali pregled podataka potrebno je odkomentirati sljedeće linije u postavkama kako bi osigurali da su defaultne postavke namještene.

   Svojstva	          Defaultna svojstva 	Opis
   Log4j.logger.DataAudit	INFO, A	Produciranje log-ova na informacijskoj razini
   Log4j.additivity.DataAudit	False	Preventiranje logg-anja root appender
   Log4j.appender.A	Org.apache.log4j.RollingFileAppender	Preventiranje logg-anja root appender
   Log4j.appender.A.File	/var/log/cassandra/audit.log	Postavljanje putanje do log datoteke
   Log4j.appender.A.bufferedlO	True	„True“ pospješuje performanse no onda sustav neće biti u „real time-u“ odnosno podaci neće pristizati unutar 3s.

3. Nadalje treba postaviti neke generalne opcije kao naprimjer odkomentirati sljedeća pravila:

   log4j.appender.A.maxFileSize = 200 MB  
   log4j.appender.A.maxBackupIndex = 5 
   log4j.appender.A.layout = org.apache.log4j.PatternLayout 
   log4j.appender.A.layout.ConversionPattern = % m % n  
   log4j.appender.A.filter.1 = com.datastax.bdp.cassandra.audit.AuditLogFilter

4. Odkomentirati te postaviti:

   log4j.appender.A.filter.1.ActiveCategories  na ALL.

5. Također preporučljivo je onemogućiti logg-anje za specifične eng. keyspaces. Kako bi to napravili potrebno je sljedeću liniju koda namjestiti na sljedeći način:

   log4j.appender.A.filter.1.E xemptKeyspaces = do_not_log, also_do_not_log

Literatura

[1] Configuring and using data auditing, https://docs.datastax.com/en/datastax_enterprise/4.6/datastax_enterprise/sec/secAudit.html

[2] Configuring audit logging to a Cassandra table, https://docs.datastax.com/en/datastax_enterprise/4.6/datastax_enterprise/sec/secAuditingCassandraTable.html

[3] How to start/stop/restart/reload iptables CentOS7/RHEL 7, http://sharadchhetri.com/2014/07/26/how-to-start-stop-restart-reload-iptables-on-centos-7-rhel-7/

[4] Running cqlsh with Kerberos/SSL, https://docs.datastax.com/en/datastax_enterprise/4.6/datastax_enterprise/sec/secRunCqlsh.html

[5] Managing object permission using intenal authorization, https://docs.datastax.com/en/datastax_enterprise/4.6/datastax_enterprise/sec/secRunCqlsh.html

[6] Secruing Spark, https://docs.datastax.com/en/latest-dse/datastax_enterprise/sec/sparkSecurity.html

[7] Setting Cassandra-specific properties, https://docs.datastax.com/en/datastax_enterprise/4.5/datastax_enterprise/spark/sparkCassProps.html

[8] Installing the Apache Cassandra 3.0 on RHEL-based systems , http://docs.datastax.com/en/cassandra/3.0/cassandra/install/installRHEL.html

[9] Configuring authentication, http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/security/security_config_native_authenticate_t.html

BigDataSecurity

Sadržaj

Cassandra + Spark security

Datastax Cassandra

Apache Spark

Pristupanje Cassandri preko Sparka

Kerberos autentifikacija

SSL

Pripremanje serverskih certifikata

Unutrašnja autorizacija Cassandrinog klastera

Kreiranje novih korisnika

Dodjeljivanje/oduzimanje prava

Konfiguracija multi-čvor sustava (iptables)

Kreiranje eng. Protocol specific lanca

Data auditing

Literatura

Osobni alati

Imenski prostori

Inačice

Pogledi

Radnje

Traži

Orijentacija

Traka s alatima