Lager 1 av säkerhetsdatabasen - dummies

Säkerhets- och sekretesskrav, lager 1 i den stora databacken, är liknande till kraven för konventionella datormiljöer. Säkerhetskraven måste anpassas nära specifika affärsbehov. Några unika utmaningar uppstår när stora data blir en del av strategin:

• Dataåtkomst: Användaråtkomst till råa eller beräknade stora data har ungefär samma tekniska krav som icke-stora dataimplementeringar. Uppgifterna bör endast vara tillgängliga för dem som har ett legitimt företagsbehov för att undersöka eller interagera med det. De flesta centrala datalagringsplattformar har rigorösa säkerhetssystem och kompletteras med en federerad identitetskapacitet, vilket ger lämplig åtkomst över de många lagren i arkitekturen.

• Tillgång till ansökan: Tillgång till data är också relativt enkel från ett tekniskt perspektiv. De flesta applikationsprogrammeringsgränssnitt (API) erbjuder skydd mot obehörig användning eller åtkomst. Denna skyddsnivå är förmodligen tillräcklig för de flesta stora dataimplementeringar.

• Datakryptering: Datakryptering är den mest utmanande aspekten av säkerhet i en stor datamiljö. I traditionella miljöer speglar kryptering och dekryptering av data systemets resurser. Detta problem förvärras av stora data. Det enklaste tillvägagångssättet är att ge mer och snabbare beräkningskapacitet. Ett mer tempererat tillvägagångssätt är att identifiera de dataelement som kräver denna säkerhetsnivå och krypterar bara de nödvändiga objekten.

• Hot avkänning: Inkluderingen av mobila enheter och sociala nätverk ökar exponentialt både mängden data och möjligheterna till säkerhetshot. Det är därför viktigt att organisationer tar ett multiperimeter tillvägagångssätt för säkerhet.

Så, med fysisk infrastruktur kan allt och säkerhetsinfrastruktur skydda alla element i din stora datamiljö. Nästa nivå i stapeln är gränssnittet som ger dubbelriktad åtkomst till alla komponenter i stapeln - från företagsapplikationer till data från Internet.

En viktig del av utformningen av dessa gränssnitt är att skapa en konsekvent struktur som kan delas både inuti och kanske utanför företaget samt med teknikpartners och affärspartners.

Programmerare har i årtionden använt API: er för att ge tillgång till och från programvaruimplementeringar. Verktygs- och teknikleverantörer kommer att gå i stor utsträckning för att säkerställa att det är en relativt enkel uppgift att skapa nya applikationer med sina produkter.Även om det är väldigt användbart, är det ibland nödvändigt för IT-proffs att skapa egna eller proprietära API-exklusiva för företaget.

Det kan hända att du behöver göra detta för att vara konkurrenskraftig, ett behov som är unikt för din organisation eller något annat företag, och det är inte en enkel uppgift. API: er måste vara väl dokumenterade och underhållna för att bevara värdet till verksamheten. Av detta skäl väljer vissa företag att använda API-verktyg för att få en start på denna viktiga verksamhet.

API-verktygen har ett par fördelar jämfört med internt utvecklade API-er. Det första är att API-verktygen är produkter som skapas, hanteras och underhålls av en oberoende tredje part. För det andra är de utformade för att lösa ett specifikt tekniskt krav.

Stora datautmaningar kräver en något annorlunda inställning till API-utveckling eller adoption. Eftersom mycket av uppgifterna är ostrukturerad och genereras utanför kontrollen av ditt företag, utvecklas en ny teknik, kallad Natural Language Processing (NLP), som den föredragna metoden för gränssnitt mellan stora data och dina applikationsprogram.

Med NLP kan du formulera frågor med naturlig språksyntax istället för ett formellt fråtspråk som SQL. För de flesta stora datanvändare är det mycket lättare att fråga "Lista alla gifta manliga konsumenter mellan 30 och 40 år som bor i sydöstra USA och är fans av NASCAR" än att skriva en 30-linjers SQL-fråga för svaret.

Eftersom de flesta datainsamling och rörelse har mycket liknande egenskaper kan du utforma en uppsättning tjänster för att samla, rensa, transformera, normalisera och lagra stora dataposter i det valbara lagringssystemet.

För att skapa så mycket flexibilitet som behövs kan fabriken köras med gränssnittsbeskrivningar skrivna i Extensible Markup Language (XML). Denna abstraktionsnivå gör det möjligt att skapa specifika gränssnitt enkelt och snabbt utan att behöva bygga specifika tjänster för varje datakälla.

I praktiken kan du skapa en beskrivning av SAP eller Oracle applikationsgränssnitt med något som XML. Varje gränssnitt skulle använda samma underliggande programvara för att migrera data mellan den stora datamiljön och produktionsapplikationsmiljön oberoende av SAP eller Oracle särdrag. Om du behöver samla data från sociala webbplatser på Internet, skulle övningen vara identisk.

Beskriv gränsytorna till sidorna i XML och engagera sedan tjänsterna för att flytta data fram och tillbaka. Vanligtvis dokumenteras dessa gränssnitt för användning av interna och externa tekniker.