Lag 1 i Big Data Stack: Sikkerhedsinfrastruktur - dummies

Sikkerheds- og privatlivskrav, lag 1 i den store datastabel er ens til kravene til konventionelle datamiljøer. Sikkerhedskravene skal nøje tilpasses til specifikke forretningsbehov. Nogle unikke udfordringer opstår, når store data bliver en del af strategien:

• Datatilgang: Brugeradgang til rå eller beregne store data har omtrent samme tekniske krav som ikke-store dataimplementeringer. Dataene skal kun være tilgængelige for dem, der har et legitimt forretningsbehov for at undersøge eller interagere med det. De fleste kernelagringsplatforme har strenge sikkerhedsordninger og forstærkes med en fødereret identitetskapacitet, der giver passende adgang på tværs af de mange lag af arkitekturen.

• Programadgang: Programadgang til data er også relativt ligetil fra et teknisk perspektiv. De fleste applikationsprogrammeringsgrænseflader (API'er) tilbyder beskyttelse mod uautoriseret brug eller adgang. Dette beskyttelsesniveau er nok nok til de fleste store data implementeringer.

• Datakryptering: Datakryptering er det mest udfordrende aspekt af sikkerhed i et stort datamiljø. I traditionelle omgivelser understreges kryptering og dekryptering af data systemernes ressourcer. Dette problem forværres med store data. Den enkleste tilgang er at give mere og hurtigere beregningsevne. En mere tempereret tilgang er at identificere de dataelementer, der kræver dette sikkerhedsniveau og kun kryptere de nødvendige elementer.

• Trusselsdetektering: Inkluderingen af ​​mobile enheder og sociale netværk øger eksponentielt både mængden af ​​data og mulighederne for sikkerhedstrusler. Det er derfor vigtigt, at organisationer tager en multiperimeter tilgang til sikkerhed.

Så, fysisk infrastruktur gør det muligt for alt og sikkerhedsinfrastruktur at beskytte alle elementer i dit store datamiljø. Det næste niveau i stakken er grænsefladerne, der giver tovejsadgang til alle komponenterne i stakken - fra virksomhedens applikationer til data feeds fra internettet.

En vigtig del af designet af disse grænseflader er skabelsen af ​​en konsistent struktur, der kan deles både inde og måske uden for virksomheden såvel som med teknologipartnere og forretningspartnere.

I flere årtier har programmerere brugt API'er til at give adgang til og fra software implementeringer. Værktøjs- og teknologileverandører vil gå langt for at sikre, at det er en forholdsvis simpel opgave at oprette nye applikationer ved hjælp af deres produkter.Selvom det er meget nyttigt, er det nogle gange nødvendigt for it-fagfolk at oprette brugerdefinerede eller proprietære API'er eksklusive til virksomheden.

Du skal muligvis gøre dette for at være konkurrencedygtig, et behov unikt for din organisation eller en anden forretningsmæssig efterspørgsel, og det er ikke en simpel opgave. API'er skal være veldokumenterede og vedligeholdes for at bevare værdien til virksomheden. Af denne grund vælger nogle virksomheder at bruge API-værktøjer til at få en start på denne vigtige aktivitet.

API-værktøjer har et par fordele i forhold til internt udviklede API'er. Den første er, at API-værktøjer er produkter, der oprettes, styres og vedligeholdes af en uafhængig tredjepart. For det andet er de designet til at løse et specifikt teknisk krav.

Store dataudfordringer kræver en lidt anden tilgang til API-udvikling eller adoption. Da mange af dataene er ustrukturerede og genereres uden for din virksomheds kontrol, fremkommer en ny teknik, kaldet Natural Language Processing (NLP), som den foretrukne metode til grænseflader mellem store data og dine applikationsprogrammer.

NLP giver dig mulighed for at formulere forespørgsler med naturlig sprogsyntax i stedet for et formelt forespørgselssprog som SQL. For de fleste store databrugere vil det være meget nemmere at spørge "List alle giftige forbrugere mellem 30 og 40 år, der bor i det sydøstlige USA og er fans af NASCAR" end at skrive en 30-linjers SQL-forespørgsel til svaret.

Da de fleste dataindsamling og -bevægelser har meget lignende egenskaber, kan du designe et sæt tjenester til at samle, rense, transformere, normalisere og gemme store dataposter i det valgte lagringssystem.

For at skabe så meget fleksibilitet som nødvendigt, kunne fabrikken køres med interfacebeskrivelser skrevet i Extensible Markup Language (XML). Dette abstraktionsniveau gør det muligt at oprette specifikke grænseflader nemt og hurtigt uden at skulle opbygge specifikke tjenester for hver datakilde.

I praksis kan du oprette en beskrivelse af SAP eller Oracle applikationsgrænseflader ved hjælp af noget som XML. Hver grænseflade ville bruge den samme underliggende software til at migrere data mellem det store datamiljø og produktionsprogrammiljøet uafhængigt af SAPs eller Oracle's specifikationer. Hvis du skal samle data fra sociale websteder på internettet, ville øvelsen være identisk.

Beskriv grænsefladerne for webstederne i XML, og kontakt derefter tjenesterne for at flytte dataene frem og tilbage. Typisk er disse grænseflader dokumenteret til brug af interne og eksterne teknologer.