EXAMENSARBETE VID NADA, KTH

Transkript

1 EXAMENSARBETE VID NADA, KTH Dokumentbaserad säkerhet i Apache Solr Document level security in Apache Solr Anders Rask e-postadress vid KTH: anrask@kth.se Exjobb i: Datasäkerhet Handledare: Henrik Eriksson Examinator: Johan Håstad Uppdragsgivare: Findwise AB

2 Dokumentbaserad säkerhet i Apache Solr Sammanfattning En sökmotor är potentiellt ett väldigt stort säkerhetshål för en organisation. Använd på fel sätt kan sökmotorn exponera känslig information som ondsinta användare då kan ta del av och utnyttja. Även om de inte kan läsa dokumenten de hittar så kan vetskapen om att informationen finns där eller kontexten den hittas i vara nog så skadlig. Detta examensarbete undersöker olika sätt att implementera en dokumentbaserad säkerhet i sökmotorn Apache Solr. Det finns i stort sett två olika metoder för sökmotorn att tillgripa när den kontrollerar säkerheten: tidig bindning eller sen bindning. I en tidig bindning lagras dokumentens säkerhetsinformation tillsammans med dokumenten i indexet och säkerheten kan därför verifieras utan inblandning från datakällan. (Det kan dock behöva hämtas information om användarens grupper) I en sen bindning lagras ingen säkerhetsinformation i indexet och datakällan måste istället tillfrågas för varje dokument som ska returneras vid en sökning ifall användaren har rätt att läsa det. Säkerhetslösningen för Apache Solr bör vara flexibel och därför ha stöd för både tidig och sen bindning. För att kunna tillämpa en tidig bindning i Apache Solr krävs först och främst en förståelse för hur säkerheten fungerar i de datakällor som lösningen ska täcka. Sedan krävs det att säkerhetslösningen efterliknar den säkerheten på ett korrekt och effektivt sätt. Vidare bör lösningen vara enkel att bygga ut till fler system och därför inför jag begreppen säkerhetsmodell och säkerhetsleverantör som utbytbara komponenter. Den förra används för att i sökmotorn efterlikna säkerheten i en datakälla och den senare används för att antingen hämta användarinformation från en datakälla eller fråga en datakälla ifall användaren kan läsa ett visst dokument. Denna rapport kommer förklara hur en säkerhetsmodell för filsystemen NTFS och UFS samt innehållshanteringssystemen Documentum och Polopoly kan se ut. Den kommer även förklara hur Documentum och Polopoly samt katalogtjänsten Active Directory kan användas som säkerhetsleverantör.

3 Document level security in Apache Solr Abstract A search engine has the potential to be a significant security threat for an organization. Implemented incorrectly the search engine may reveal sensitive information which can be abused by a malicious user. Even if they cannot read the documents they find, simply knowledge of their existence or the context in which they are found can be damaging enough. This master thesis examins different ways to implement a document level security in the search engine Apache Solr. There are two significant ways in which a search engine may protect its information: early binding and late binding. In an early binding the document s security information is stored together with the document in the index. Therefore, access rights can be verified without any involvement from the datasource. (It may however need information about the user s groups) In a late binding no security information is stored in the index and the search engine must instead ask the data source for every document in the search result whether the user is allowed to read it or not. The security solution for Apache Solr should be flexible and should therefore have support for both early and late binding. In order to implement an early binding in Apache Solr it is important to have a deep understanding of how the security works in the underlying data source. It is important that the security solution is able to emulate this security in a correct and effective manner. The solution should also be easily extendable to other systems. Therefore, I introduce the terms security model and security provider as replacable components. The first is used in the search engine to emulate the security model of a data source and the second is used to either collect user information from a data source or to ask a data source if a user can read a certain document. This report will explain how a security model for the file systems NTFS and UFS, and the content management systems Documentum and Polopoly can look like. It will also explain how Documentum, Polopoly and the directory service Active Directory can be used as a security provider.

4 Bakgrund Det har hänt mycket inom området sökteknologi de senaste åren, men trots detta är det fortfarande ett relativt outvecklat område. Till skillnad från den allmänna uppfattningen är området inte färdigupptäckt bara på grund av Googles väldiga framfart. Framförallt finns det mycket utveckling kvar att göra för att även andra datakällor än World Wide Web ska bli enkla att söka i. Ett exempel är ett företags eller organisations intranät, där det ofta finns stora mängder information. För att göra denna information mer lätthanterlig för användarna är moderna sökteknologilösningar ett bra verktyg. På marknaden finns idag ett antal olika produkter som tillhandahåller söklösningar åt företag och organisationer. För att nämna några IDOL av Autonomy, Fast ESP av Microsoft och Google Search Appliance av Google. Förutom dessa proprietära produkter finns det en sökmotor med öppen källkod kallat Solr som är baserat på det likaså öppna sökmotorbiblioteket Lucene. Båda dessa utvecklas under Apache projektet. Examensarbetet är utfört på Findwise AB i Stockholm. Findwise affärsidé är att tillhandahålla kompetens på sökteknologiområdet. Med hjälp av någon av de sökprodukter som finns på marknaden idag så skapar Findwise anpassade söksystem åt företag och organisationer. Detta examensarbete fungerar som en del i att skapa mer kommersiell nytta kring Apache Solr. Rent konkret behandlar examensarbetet området datasäkerhet, och mer specifikt hur man skyddar dokument från att kunna sökas i Apache Solr av användare som inte har rättigheter att läsa dem i den ursprungliga datakällan. Detta är en väldigt viktig aspekt för många företag då det ofta finns dokument som alla anställda inte får ta del av. Alla proprietära system nämnda ovan har en lösning på detta problem medan Apache Solr förnärvarande saknar detta. Problem Hur säkerställer man att dokument indexerade från en eller flera datakällor inte kan ses vid en sökning av en person som inte har rätt att läsa dessa i den ursprungliga datakällan samt hur kan detta implementeras i Apache Solr. Syfte Detta examensarbete syftar till att undersöka hur en säkerhetslösning för dokumentbaserad säkerhet kan se ut i Apache Solr för innehållshanteringssystemen Documentum och Polopoly samt filsystemen NTFS och UFS. Denna undersökning ska även tillämpas i en prototyp som ska ge dokumentbaserad säkerhet i NTFS med stöd för att hämta användarinformation från Active Directory.

5 Innehållsförteckning Teoretisk grund Sökmotorer Sökmotorer och säkerhet Apache Solr Apache Lucene Säkerhet i Solr Åtkomstkontroll Ticket eller Access Control List Mellanliggande strukturer Filsystem NTFS UFS Innehållshanteringssystem Polopoly Documentum Katalogtjänster Active Directory En säkerhetslösning för Solr Säkerhetskomponenten i Solr Stöd för olika säkerhetsmodeller NTFS UFS Documentum Polopoly Stöd för olika säkerhetsleverantörer Active Directory Documentum Polopoly Analys av alternativa lösningar SearchComponent Tidig och sen bindning Säkerhetsleverantör och säkerhetsmodell Genomgång av prototypen Konfiguration av prototypen Implementation av prototypen ACL-extrahering från NTFS Slutsatser Litteraturlista... 32

6 1. Teoretisk grund Kapitel 1 Teoretisk grund Detta kapitel behandlar alla de olika områden som detta examensarbete berör. Tanken är att den ska ligga som en grund för resten av rapporten och skapa den förståelse som är nödvändig. 1.1 Sökmotorer Sökmotorn är den programvara bakom en söktjänst som möjliggör indexering av och sökning i stora textmassor. En sökmotor är bra på att hantera stora mängder ostrukturerad text. Detta i kontrast till en databas som är byggd för att hantera stora mängder strukturerade data. Figur 1 som är tagen från Konchady (2008) visar skillnaden mellan sökning i en databas och i en sökmotor. Till en databas ställs en SQL-fråga och en lista av rader innehållandes strukturerad data returneras. Medan det till en sökmotor ställs en boolesk fråga och en lista av referenser till dokument som träffats av frågan returneras. SQL fråga Lista av rader TABELLER Databas Student Namn Nummer Kurs Namn Nummer Sökning Boolesk fråga INDEX... Sökmotor Lista av referenser Figur 1: Sökning i databas och sökning i sökmotor (Konchady, 2008). En sökmotor, som illustreras i figur 2, består av tre komponenter: en spindel, en indexerare och ett sökgränssnitt (Konchady, 2008). Datakälla Spindel Indexerare Sökmotor Index Sökgränssnitt Figur 2: Sökmotorarkitektur. Figur 2 illustrerar hur spindeln hämtar data från en datakälla och skickar dessa vidare till indexeraren. Spindeln kan antingen vara en del av sökmotorapplikationen, en fristående applikation eller en del av datakällan. Som Konchady (2008) beskriver finns det olika sorters 1

7 1. Teoretisk grund spindlar som till exempel kan traversera ett lokalt filsystem, gå igenom ett intranät/internet eller hämta dokument från ett innehållshanteringssystem. Efter det att spindeln har hämtat data från datakällan skickas de till indexeraren (se figur 2). Dess huvuduppgift är att bygga indexet. Innan texten indexeras extraherar indexeraren den från dokumentet. Textextraheringen måste göras på olika sätt beroende på vilken filtyp dokumentet är. Större delen av texten tillhör oftast dokumentets huvuddel, men beroende på filtyp tillkommer olika metadata till dokumentet, till exempel författarens namn. När texten är extraherad analyseras den för att finna de informationsbärare (tokens) som ska indexeras. I sin enklaste form är varje informationsbärare ett ord, men oftast duger inte det utan man vill till exempel kunna indexera ett företagsnamn som en informationsbärare. Som Hatcher et al (2009) konstaterar kan analysen göras på många sätt: Hur hanteras sammansatta ord? Ska rättstavning på texten tillämpas? Ska synonymer till ord skjutas in i den indexerade texten? Ska orden i texten göras om till sin grundform? Det finns många sådana frågor som måste besvaras innan indexet kan byggas. Indexet i de allra flesta sökmotorer är ett så kallat inverterat index. Det inverterade indexet är en kompakt datastruktur (Konchady, 2008). För att förstå hur säkerheten för de indexerade dokumenten fungerar senare i denna rapport krävs en grundläggande förståelse för hur ett inverterat index fungerar. Det som gör indexet inverterat är att informationsbärarna används som uppslagsord till dokumenten; informationsbäraren istället för dokumentet är alltså den centrala enheten. Hatcher et al (2009) förklarar det så här: istället för att svara på frågan Vilka ord ingår i det här dokumentet? så svarar det inverterade indexet på frågan Vilka dokument innehåller ord X?. Som exemplifieras i tabell 1 och 2 lagrar det inverterade indexet alla informationsbärare med hänvisningar till i vilka dokument de finns. Ett riktigt inverterat index hade förutom dessa referenser även lagrat var i dokumentet de påträffats. Något som kan noteras är att de vanliga orden på och en inte har indexerats. Tabell 1: Lista på dokument och tillhörande text (Konchady, 2008). Dokument Id Text 1 Kalle satt på Nils. 2 Nils såg Kalle. 3 Kalle fick en katt. Tabell 2: Inverterat index över dokumenten i tabell 1 (Konchady, 2008). Ord Dokument Kalle 1, 2, 3 satt 1 Nils 1, 2 fick 3 Katt 3 När indexet är skapat kan det sökas i. Sökning sker genom att sökmotorn tillhandahåller ett gränssnitt (se figur 2). Mycket kan göras för att förbättra utfallet av en sökning, men prestandan för sökningar är oftast väldigt viktigt så allt för tidskrävande operationer bör undvikas. Vilket kommer framgå av denna rapport är dokumentsäkerhet en sådan sak som riskerar att bli alldeles för tidskrävande ifall den görs på fel sätt Sökmotorer och säkerhet Sökmotorer som indexerar webben, till exempel Google, undviker att indexera sådan information som allmänheten har begränsad åtkomst till. Detta på grund av att belastningen för 2

8 1. Teoretisk grund att säkerställa säkerheten för resultaten skulle bli enorm med den mängd dokument och det antal användare som finns på webben (Bailey et al, 2006). En sökmotor som indexerar ett intranät kan dock inte göra det valet. Det finns flera olika säkerhetsaspekter att ta i beaktande för att en sådan sökmotor ska kunna anses säker. Detta examensarbete fokuserar på säkerheten för den indexerade texten vid sökningar. Det vill säga att otillåtna personer inte ska kunna läsa information de inte är behöriga till, eller ens se att den existerar. Textsäkerhet kan implementeras på flera olika nivåer: Datakälla med säkerhet på källnivå får en användare antingen läsa all information från en datakälla eller ingen alls. Dokument med säkerhet på dokumentnivå har användare olika rättigheter till olika dokument. Detta är ett populärt sätt att lösa säkerheten på då många källsystem hanterar säkerheten på detta sätt. Det är också det sätt som detta examensarbete kommer att fokusera på. Fält med säkerhet på fältnivå delas ett dokument upp i flera fält där användare har olika rättigheter till olika fält. Att implementera säkerheten på dokumentnivå betyder att man oftast kan använda de befintliga säkerhetsstrukturerna för filer som finns i datakällan. Det vanligaste är att säkerheten för filerna i datakällan är implementerad med en Access Control List (ACL) för varje fil. Mer om detta under rubriken 1.3 Åtkomstkontroll. Det finns två huvudsakliga strategier att använda vid implementering av säkerhet i en sökmotor: tidig bindning och sen bindning. Tidig bindning Fil rapport.doc ACL kalle: läsa, skriva anställda: läsa Användare: Nils Datakälla Spindel Sökmotor Grupp: anställda Användarinformation Figur 3: Datakälla indexerad med tidig bindning, samt sökning i denna. Figur 3 illustrerar en tidig bindning med två moment som sker vid olika tidpunkter: indexering och sökning. Vid indexering läser spindeln in ACL-informationen tillsammans med filen rapport.doc. Som ACL-informationen visar har användaren kalle rättigheter att läsa och skriva medan gruppen anställda endast har rättigheter att läsa rapport.doc. Texten samt vilka användare och grupper som har läsrättighet till filen skickas vidare till indexeraren för indexering. ACL-informationen lagras alltså som metadata till dokumentet i indexet. När användaren Nils vid en annan tidpunkt söker efter rapport.doc efterfrågar sökmotorn först vilka grupper Nils tillhör och matchar sedan dessa samt Nils användarnamn mot ACL-metadatan till rapport.doc. Matchningen kan ske genom att sökmotorn ovanpå Nils fråga lägger ett filter som filtrerar bort alla dokument som inte har korrekt ACL-metadata. 3

9 1. Teoretisk grund Sen bindning Sökmotor Sökning Sökresultat Användare: Nils Fil Fil rapport.doc JA text.txt NEJ Filtrering på användare Nils Datakälla Figur 4: Sen bindning använd mot datakälla. I en sen bindning lagras ingen ACL-information i indexet utan istället tillfrågas datakällan om användaren har rättighet att läsa ett visst dokument. I figur 4 visas hur användare Nils gör en sökning. Resultatet på denna sökning måste innan den returneras filtreras genom att datakällan tillfrågas om Nils har rättigheter att läsa dokumenten. Detta måste göras för varje dokument som ska returneras i sökresultatet. I det illustrerade exemplet kommer endast rapport.doc att returneras eftersom Nils inte har rättigheter att läsa text.txt. Det riskerar förstås att bli en kostsam process i de fall då en användare söker på ett ord som förekommer i väldigt många dokument men användaren bara har rättighet att läsa ett fåtal av dessa. 1.2 Apache Solr Apache Solr, eller Solr som jag kommer benämna den i resten av texten, är öppen källkod och utvecklas under Apache Software Foundation. Solr bygger på sökmotorn Lucene och är en sökmotorserver som ska köras i en Java servlet container, till exempel Apache Tomcat (Solr hemsida). 4

10 1. Teoretisk grund DispatchFilter RequestHandler ResponseWriter Search Search Component Component Solr core Lucene Solr Figur 5: Hantering av sökning och resultat i Solr. I figur 5 visas en förenklad bild av hur en sökning i Solr hanteras. Den innehåller de huvudsakliga aktörerna och visar vilken väg en sökning tar för att producera ett resultat till användaren. 1. En sökning kommer in via HTTP till ett filter (dispatch filter) som bestämmer, beroende på konfiguration eller användarval, vilken Request Handler den ska skicka sökningen till. 2. Vald Request Handler anropar sedan de Search Components som är konfigurerade till den. a. Först prepare i vilken alla Search Components får en chans att ändra sökningen eller göra annat innan den utförs. b. Sedan process där alla får en chans att agera utifrån resultatet på sökningen. 3. När Request Handlern har returnerat anropar filtret vald Response Writer som skriver resultatet i rätt format. 4. Resultatet returneras till användaren. Indexering av dokument i Solr sker genom en XML-syntax som skickas med HTTP POST meddelanden. Sökning sker även det över HTTP, men här i form av HTTP GET förfrågningar Apache Lucene Lucene är precis som Solr öppen källkod och ett Apache projekt. Det är ett sökmotorbibliotek som tillhandahåller indexering och sökning åt applikationer som till exempel Solr. Den är i sig alltså inte i första hand en fristående applikation. 5

11 Administrationsgränssnitt Analyseringsgränssnitt Dokumentsäkerhet i Apache Solr 1. Teoretisk grund Sökgränssnitt Bygg fråga Rendera resultat Utför fråga Index Indexera dokument Analysera dokument Bygg dokument Hämta data Figur 6: En sökmotor med Lucene. Figur 6, från Hatcher et al (2009), visar hur en applikation kan använda sig av Lucene. De grå delarna är sådant som Lucene sköter och de vita delarna sköts av den applikation som använder Lucene, så som Solr Säkerhet i Solr Solr har ingen inbyggd säkerhet för text eller kommunikation (Solr hemsida). 1.3 Åtkomstkontroll Åtkomstkontroll är en fundamental del av området datasäkerhet och så också i detta examensarbete, det är faktiskt just det som detta arbete syftar till att implementera i Solr. Som Gollman (2006) berättar används åtkomstkontroll på många olika sätt i en dator eller ett system. Ofta handlar kontrollen om integriteten för data, det vill säga att två samtidiga instanser inte ska få skriva samtidigt till samma minnesområde. Det som menas i denna rapport och som är intressant från en användares perspektiv är dock åtkomstkontroll över vilka filer hon får eller inte får läsa. Användare/ subjekt Operation Referensmonitor Objekt Figur 7: Åtkomstkontroll. Åtkomstkontroll, i den mening som illustreras av figur 7, består enligt Gollman (2006) av två steg, autentisering av användaren och auktorisering av användaren på ett visst objekt. Som visas i figur 7 kan åtkomstkontroll illustreras av att ett subjekt, till exempel en applikation, använder en användares identitet till att utföra en operation på ett objekt. En referensmonitor säger då om detta är tillåtet eller ej. 6

12 1. Teoretisk grund Det finns olika sätt att lagra de rättigheter en användare har till ett objekt. Det mest elementära sättet är att lagra alla rättigheter i en matris, en så kallad Access Control Matrix, där alla användare i systemet finns längs den vertikala axeln och alla objekt i systemet längs den horisontella. Rättigheterna för en användare till ett visst objekt skulle då ges av den cell som ligger i användarens rad och objektets kolumn. Detta är dock ingen bra modell för ett system som innehåller väldigt många objekt och användare eller då rättigheterna ändras ofta (Gollman, 2006). Istället lagrar man rättigheterna antingen hos användarna eller hos objekten Ticket eller Access Control List Då rättigheterna lagras hos användarna talar man om capabilities (förmågor). Som Gollman (2006) skriver finns det problem med att lagra rättigheterna hos användarna. Det är väldigt svårt att få en överblick över vilka användare som har rättigheter till ett visst objekt och det blir således väldigt svårt att dra in eller ändra rättigheterna till ett objekt. I takt med att distribuerade system blir allt vanligare blir emellertid detta sätt att hantera rättigheter vanligare. I distribuerade system sköts detta ofta med hjälp av en ticket som användaren tar med sig mellan systemen. Då rättigheterna lagras hos objekten talar man om Access Control Lists. Detta är det vanligaste sättet att hantera rättigheter i kommersiella operativsystem (Gollman, 2006) men används även flitigt i andra system som behöver hantera rättigheter. Det är således ett centralt begrepp för detta examensarbete. Med en Access Control List (ACL) lagras rättigheterna till ett objekt hos objektet. Detta gör det enkelt att åstadkomma en tidig bindning i Solr. Eftersom ACL-informationen är kopplad till objektet kan systemet tillfrågas om vilka rättigheter som finns på objektet vid indexeringstid och därefter lagra dessa i indexet enligt förfarandet vid tidig bindning. Mapp exempel/ Fil Fil Fil rapport.doc program.exe text.txt ACL kalle: läsa, skriva lisa: läsa ACL kalle: exekvera lisa: exekvera ACL kalle: läsa, skriva lisa: läsa, skriva Figur 8: ACL-information kopplad till filer i ett filsystem. I figur 8 visas hur ACL-informationen kan se ut för filer i ett filsystem. Det finns två användare: Kalle och Lisa. Medan Kalle har rättigheter att både läsa och skriva rapport.doc har Lisa endast rättighet att läsa denna. Båda har rättigheter att exekvera program.exe samt att läsa och skriva text.txt Mellanliggande strukturer För att göra det enklare att administrera rättigheterna i stora system finns det ofta en eller flera mellanliggande strukturer. De jag kommer referera till i denna rapport är tre olika strukturer: grupper, roller samt negativa rättigheter. Grupper och roller används för att ge samma rättigheter till flera användare som har något gemensamt. I samband med detta kan negativa rättigheter användas för att ge administratören mer flexibilitet. 7

13 1. Teoretisk grund Grupper är något som existerar i de flesta av de mer avancerade säkerhetsmodellerna. Antingen så att användaren bara kan vara medlem av en grupp, men oftare att hon kan vara medlem i flera grupper samtidigt. Tanken är att man ska samla de användare som ska ha tillgång till samma information i samma grupp och sedan ge denna grupp rättigheter till de berörda objekten. Grupper förenklar administrationen av rättigheter väsentligt. u 1 u 2 u 3 u 4 u 5 Användare g 1 g 2 Grupper o 1 o 2 o 3 o 4 o 5 o 6 Objekt Figur 9: Användare i grupper. I figur 9, tagen från Gollmans (2006) bok, visas ett system där alla användare är med i en eller två grupper och dessa grupper har sedan tilldelats rättigheter till ett antal objekt. Detta är idealfallet, när endast grupperna behöver tilldelas rättigheter. I verkligheten kan man dock behöva ge enskilda användare speciella rättigheter eller frånta dem rättigheter som gruppen har. För att administrera detta finns det i många säkerhetsmodeller en möjlighet att ge negativa rättigheter till en användare eller en grupp, det vill säga frånta användare rättigheter som de annars skulle haft. u 1 u 2 u 3 Användare g 1 Grupper o 1 o 2 o 3 o 4 o 5 Objekt Figur 10: Negativ rättighet. I figur 10 (Gollman, 2006) visas hur användare u 1 inte har rättigheter till objekt o 1 trots att den grupp användaren är med i har dessa rättigheter. En annan typ av mellanliggande struktur är roller. Role-Based Access Control (RBAC) används inte så flitigt i operativsystem men är vanligare i databaser (Gollman, 2006) och i vissa innehållshanteringssystem. En användare av ett sådant system kan bara befinna sig i en roll i taget och alla användare med samma roll har då samma rättigheter till samma objekt. Alla dessa mellanliggande strukturer är viktiga för utformningen av den säkerhetslösning för Solr som detta examensarbete lägger fram. 1.4 Filsystem Det finns många olika filsystem ute på marknaden. Den säkerhetslösning för Solr som beskrivs i denna rapport påverkas av hur säkerhetsmodellen ser ut i de filsystem den ska stödja. Säkerhetslösningen ska vara så flexibel att det ska vara enkelt att lägga till stöd för olika 8

14 1. Teoretisk grund filsystem. Prototypen som beskrivs i senare kapitel kommer att ha stöd för NTFS, men jag kommer även redogöra för hur ett stöd för Unix-system som använder POSIX rättigheter kan se ut NTFS NTFS (New Technology File System) är det filsystem som har använts i Microsoft Windows sedan versionerna NT/XP. NTFS är ett avancerat filsystem som det kan skrivas åtskilligt om. Det som är relevant för denna rapport är dock bara hur åtkomstkontroll för filerna fungerar. NTFS säkerhetsmodell bygger på en ACL-struktur där varje objekt har en länk till en Security Descriptor som finns lagrad i en metadatafil kallad $Secure. Varje Security Descriptor är unik och delas av de objekt som har likadana rättigheter. Detta leder till effektivare utnyttjande av diskutrymme. Security Descriptorns delar förklaras av tabell 3. Tabell 3: Security Descriptor (NTFS.com). Fält Förklaring Huvud Owner_SID Group_SID DACL SACL Revisionsnummer och kontrollflaggor till security descriptorn. Security Identifier för ägaren av objektet. Security Identifier för ägarens huvudgrupp. Discretionary Access Control List. Kontrollerar åtkomsträttigheter för objektet. System Access Control List. Kontrollerar loggning av åtkomstförsök till objektet. Till varje objekt hör alltså två olika ACL:er: DACL och SACL. DACL kontrollerar vilka användare eller grupper som har rättigheter till objektet medan SACL kontrollerar hur loggning av åtkomster till objektet ska ske för olika användare och grupper. Ägaren till objektet är den som kontrollerar innehållet i DACL:en, medan det är systemadministratörerna som kontrollerar innehållet i SACL:en. För säkerhetslösningen i Solr är endast DACL:en av betydelse. Varje ACL (DACL och SACL) innehåller en ordnad lista av Access Control Entries (ACE). I en ACE definieras vad en användare eller grupp får göra (DACL), inte får göra (DACL) eller loggas när de gör (SACL). Tabell 4: NTFS avancerade och grundläggande rättigheter (NTFS.com). Rättigheter Full kontrol Ändra Läsa & exekvera Lista mappinnehåll Läsa Skriva Traversera mapp/exekvera fil x x x x Lista mapp/läsa data x x x x x Läs attribut x x x x x Läs utökade attribut x x x x x Skapa filer/skriv data x x X Skapa mappar/bifoga data x x X Skriv attribut x x X Skriv utökade attribut x x X Radera undermapp och filer x Radera x x Läs rättigheter x x x x x X Ändra rättigheter x Ta ägarskap x Synkronisera x x x x x X I tabell 4 visas NTFS alla olika rättighetstyper. Raderna innehåller de mer specifika avancerade typerna och kolumnerna visar vilka avancerade rättigheter som hör till vilka grundläggande rättigheter. När ACL:en indexeras i sökmotorn är det intressanta vilka som har rättigheten lista mapp/läsa data. 9

15 1. Teoretisk grund I NTFS kan ett objekt få rättigheter på två sätt: explicit och genom arv. Explicita rättigheter är sådana som sätts antingen när objektet skapas eller av en användare. Ärvda rättigheter ges till barnobjekt av dess föräldrar, alltså när en fil ärver rättigheter från den mapp den ligger i. NTFS innehåller också negativa rättigheter. En användare eller grupp kan alltså nekas rättigheter till ett objekt som den eller de annars skulle haft. När NTFS ska göra en åtkomstkontroll följer den DACL:ens ACE:er i ordning. Dessa är placerade utefter ett speciellt företrädesschema som ser ut som följer (NTFS.com): 1. Explicit negativ rättighet. 2. Explicit positiv rättighet. 3. Ärvd negativ rättighet. 4. Ärvd positiv rättighet. Även inom de ärvda rättigheterna sker ett företräde, först för ett objekts förälder och därefter dess förförälder och så vidare. När NTFS kalkylerar användarens rättigheter på ett objekt följer den alltså denna ordning och stannar så fort den efterfrågade rättigheten är satt. Om detta är en negativ rättighet så avslås begäran på objektet, om det är en positiv rättighet så godtas det. Hittas inte den rättighet som är efterfrågad så avslås begäran UFS UFS (UNIX File System) är standardfilsystemet som kommer med Sun Solaris. Som McDougall et al (2006) berättar har UFS traditionellt sett en ganska enkel filrättighetsmodell där användare ges rättigheter baserat på tre kategorier: 1. Ägare. 2. Ägarens grupp. 3. Världen (alla andra). Figur 11 (McDougall et al, 2006) visar en utskrift av kommandot ls l för filen rapport.doc och exemplifierar hur filer i denna modell kan ha olika rättigheter för ägaren, ägarens UNIX grupp och världen (alla andra). Användare i ägarens grupp kan läsa filen Användare utanför ägarens grupp kan läsa filen -rw-r--r-- 1 kalle anställda Apr 2 18:29 rapport.doc Ägaren kan läsa och skriva filen Filägarens användarnamn Filägarens grupp Figur 11: Traditionella rättigheter i UNIX. Det finns tre olika rättigheter som kan ges: r för läsning, w för skrivning och x för att kunna exekvera en fil. För att kontrollera en användares åtkomst till en fil används dess uid (user id) och gid (group id) på följande sätt (Gollman, 2006): Om användarens uid sammanfaller med filägarens uid används ägarens rättigheter för att kontrollera åtkomsten. Om användaren inte är ägare till filen men dess gid är samma som gruppen som äger filen används gruppens rättigheter för att kontrollera åtkomsten. Om varken användarens uid eller gid ger rättigheter så används rättigheterna för världen för att kontrollera åtkomsten. 10

16 1. Teoretisk grund Detta kan ge upphov till det något märkliga fallet att alla andra har mer rättigheter till en fil än vad ägaren har. Det kan ses som en form av negativa rättigheter då man nekas åtkomst till filer man annars borde ha rättigheter till men används inte på detta sätt. Modellen blir lite mer flexibel genom att det är möjligt att vara medlem av flera grupper och byta mellan dessa för att få rättigheter till olika filer. I och med att en användare bara kan vara medlem av en grupp åt gången liknar det mer Role-Based Access Control än en vanlig gruppbaserad säkerhet. McDougall et al (2006) påpekar även att det existerar en mer flexibel ACL-funktion där man kan tilldela enskilda användare och grupper olika rättigheter. Men då detta enligt min erfarenhet sällan används i UNIX kommer jag inte att beröra det i denna rapport. 1.5 Innehållshanteringssystem En säkerhetslösning för Solr bör ha stöd för flera olika innehållshanteringssystem. Då säkerhetsmodellen ser olika ut från system till system krävs det att lösningen använder olika strategier för att skydda dokument som kommer från olika system. Jag har tittat närmare på två olika system och vad som krävs för att göra en implementation för dessa Polopoly Polopoly är ett innehållshanteringssystem främst riktat mot stora nyhetsorganisationer. Polopoly version 9 bygger på en Java 2 Enterprise Edition (J2EE) arkitektur. All text, alla dokument och andra resurser hanteras som Java objekt och lagras i en relationsdatabas. Systemet är uppdelat på olika containrar och moduler som hanterar olika delar av systemet (Polopoly utvecklarguide): 1. Webbcontainern Tillhandahåller all användarinteraktion genom olika gränssnitt som administreringsgränssnitt, publiceringsgränssnitt och läsgränssnitt. 2. Enterprise JavaBean (EJB) containern Är kärnan i systemet och innehåller två moduler, en som hanterar användare och en som hanterar innehåll. 3. Java Message Service (JMS) modul Används för att skicka och ta emot meddelanden om händelser i systemet. 4. Java Server Mbeans Används för att monitorera och hantera systemet. Säkerhet i Polopoly Polopoly kan använda sig av ett av två olika sätt för att skydda dess information från otillåten åtkomst (Polopoly utvecklarguide): Rättighetsträd där rättigheterna lagras som ACL:er för varje objekt. Användarrättigheter där rättigheterna är lagrade i användarinformationen. Rättighetsträd är flexibla men tidskrävande medan användarrättigheter tvärtom är snabba men inflexibla. Rekommenderat är att använda användarrättigheter på stora publika webbplatser och rättighetsträd på intranät. Ett rättighetsträd är en hierarki där varje informationsobjekt har en security parent från vilken den ärver rättigheter. I Polopoly tillhör varje objekt ett så kallat huvudämne (major) som definierar vilken typ av objekt det rör sig om, till exempel artikel-, departements- eller användarobjekt. Vissa rättigheter sätts så att de endast berör de objekt som tillhör ett visst huvudämne. Med hjälp av dessa huvudämnen kan till exempel alla artiklar i ett rättighetsträd ges vissa rättigheter medan alla departement i trädet ges andra rättigheter. De rättigheter som existerar i systemet visas i tabell 5. Denna visar även vilka rättigheter som sätts med beroende på huvudämne. Tabell 5: Rättigheter i Polopoly (Polopoly utvecklarguide). Rättighet Förklaring Sätts med huvudämne READ Krävs för att kunna se och läsa innehåll. Ja 11

17 1. Teoretisk grund WRITE Krävs för att kunna låsa ett objekt för editering. CREATE Krävs för att kunna skapa innehåll. Ja REMOVE Krävs för att kunna ta bort innehåll. Ja CREATE_ACL REMOVE_ACL UNLOCK LIST-INPUT-TEMPLATE-CATEGORY Krävs för att kunna skapa en ACL kopplad till ett objekt. Krävs för att kunna ta bort en ACL kopplad till ett objekt. Krävs för att kunna låsa upp innehåll låst av någon annan. GUI-kontrollerad rättighet för att bestämma vilken mall en användare ska ha när denna skapar ett objekt. För att kontrollera om en användare har en viss rättighet till ett objekt följer systemet rättighetsträdet från objektet till roten. Först kontrolleras det ifall denna rättighet ges i ACL:en som hör till objektet. Existerar inte den korrekta rättigheten här kontrolleras rättigheten istället i objektets security parent. Detta fortsätter sedan tills roten på trädet har nåtts. Har användaren då inte fått de rättigheter som krävs så avslås begäran. I Polopolys säkerhetsmodell med rättighetsträd kan en användare vara medlem av en eller flera grupper, dessutom kan även en grupp vara medlem av en annan grupp. Användarrättigheter har en enklare modell än rättighetsträd. Här lagras de rättigheter en användare har rätt att utföra på alla objekt i Polopoly hos användaren. Rättigheter kan också ges så att de endast gäller en viss tidsperiod Documentum Documentum är ett innehållshanteringssystem utvecklat av EMC. Det är gjort för att hantera en stor mängd dokument. Några av de saker Documentum tillhandahåller är (Documentum Developer): Säkerhet Versionshantering Arbetsflöde Händelseavisering Documentum bygger på en specialiserad relationsdatabas där dokument och dess metadata kan hämtas och modifieras med hjälp av ett specialiserat språk kallat Documentum Query Language (DQL) vilket är en utbyggnad av det standardiserade Structured Query Language (SQL) som brukar användas i relationsdatabaser. För att prata med en relationsdatabas används i Java ett API kallat Java DataBase Connectivity (JDBC). För att prata med Documentum genom JDBC krävs något som kallas en econnector (Documentum Developer). Med hjälp av denna kan Documentum frågas genom DQL och information om dokument eller användare kan hämtas. Säkerhet i Documentum I Documentum administreras åtkomstkontroll genom att varje objekt i systemet tilldelas en ACL som styr vem som har vilka rättigheter till objektet. ACL:en kan ge rättigheter till en specifik användare, en grupp med användare eller en roll som en användare kan ha. Tabell 6 visar vilka olika rättighetsnivåer som finns i Documentum. En högre nivå ger automatiskt alla de rättigheter som en lägre nivå ger. Till exempel ger relatera även rättighet att bläddra och att läsa. Tabell 6: Rättighetsnivåer i Documentum (Säkerhet i EMC Documentum). Ja Ja Ja Nej Nej Rättighetsnivå Ingen Förklaring Inga objekt med denna nivå ses. 12

18 1. Teoretisk grund Bläddra Läsa Relatera Version Skriva Radera Objekt kan ses men inte läsas. Objekt kan öppnas och läsas men inte skrivas. Relationer kan skapas från ett objekt till ett annat. Ändringar kan göras på objekt men dessa sparas som en ny version. Ändringar till den befintliga versionen kan göras. Objekt kan raderas. En grupp i Documentum kan ges egenskapen dynamisk. Detta innebär att auktoriserade applikationer (inte användare) kan flytta användare in och ut ur dessa grupper och på så sätt styra användarens rättigheter beroende på yttre omständigheter. Dessa dynamiska grupper kan enligt Säkerhet i EMC Documentum ses som en variant av Role-Based Access Control (RBAC). För att få tillgång till en mer avancerad säkerhetsmodell i Documentum finns det två olika tilläggslicenser som kan läggas till den vanliga säkerheten: Collaboration Services och Trusted Content Services (Säkerhet i EMC Documentum). Collaboration Services ger möjligheten att skapa så kallade rum i Documentum. Ett rum kan ses som en avgränsad del av Documentum (men kan vara uppblandad med resten) som bara vissa användare har rätt att se. Rummen utökar Documentums säkerhetsmodell med ett antal egenskaper (Säkerhet i EMC Documentum): Självadministration Bra i en ad hoc miljö där olika projekt ska kunna administrera sig själva. Åtkomstreglering Medlemskap i rummen styrs genom en speciell grupp kallad medlemsgruppen. Endast de som är medlemmar av denna grupp får se den data som ingår i rummet. Lokala grupper Rummets ägare kan skapa lokala grupper och roller som medlemmarna av rummet kan ingå i och på så sätt få olika rättigheter till rummets objekt. Reglerade objekt De objekt som ingår i ett rum kallas för reglerade objekt. Genom att sätta ACL-fältet required group till ett rums medlemsgrupp så placerar man objektet i detta rum. Trusted Content Services (TCS) lägger till ett antal nya säkerhetsredskap till Documentum, såsom (Säkerhet i EMC Documentum): Kryptering av datakällan. Elektroniska signaturer. Flerdimensionell åtkomstkontroll Digital strimling (digital shredding). För detta arbete är dock endast det som Documentum kallar flerdimensionell åtkomstkontroll betydelsefull. Rummen i Collaboration Services är en form av flerdimensionell åtkomstkontroll. TCS utvidgar dock begreppet ytterligare och gör det möjligt att kontrollera åtkomst beroende på medlemskap i vissa grupper och icke-medlemskap i andra grupper. Till exempel kan åtkomsten regleras till de som är medlemmar av både ledningsgruppen och VD gruppen, eller medlemmar av exekutiva VD gruppen, samtidigt som de inte är medlemmar av sälj- eller kundrelationsgruppen. Detta exempel illustreras av mängderna i figur

19 1. Teoretisk grund Figur 12: Flerdimensionell åtkomstkontroll i Documentum (Säkerhet i EMC Documentum). 1.6 Katalogtjänster En katalogtjänst är en datakälla för att lagra nätverksinformation som ska användas av många applikationer och användare. De används ofta för att lagra information om användare och grupper i stora organisationer. Den katalogtjänst jag kommer redogöra för här är Microsofts Active Directory Active Directory Active Directory är Microsofts katalogtjänst. Byggt ovanpå Windows 2000, Windows Server 2003 eller Windows Server 2008 bildar det ett så kallat nätverksoperativsystem (NOS). Som Desmond et al (2008) skriver bygger Active Directory på katalogtjänstprotokollet Lightweight Directory Access Protocol (LDAP). Protokollet kan ses som en standard som de flesta av dagens katalogtjänster stödjer. Active Directory bygger på en struktur uppdelad på domäner där dessa tillsammans kan tillhöra en skog. I Active Directory lagras alla data som objekt. Vilka typer av objekt som finns och hur dessa är uppbyggda bestäms av ett schema. Till exempel är användare och grupp två objekt som kan lagras i Active Directory. Det är också dessa två objekt som är intressanta då Active Directory används i säkerhetslösningen för Solr. Med hjälp av ett användarnamn kan användarobjektet hittas i Active Directory. Ur detta objekt kan man sedan få reda på vilka grupper användaren är medlem i. Även gruppobjekten är intressanta eftersom det i till exempel NTFS säkerhetsmodell är möjligt för en grupp att vara medlem av en annan grupp. Alltså måste hela kedjan av grupper i grupper lösas för att få reda på vilka rättigheter en användare i slutändan får. Detta görs genom att söka upp gruppobjektet i Active Directory och ta reda på om denna grupp är medlem av andra grupper och så vidare. Active Directory består av en trädstruktur som i senare versioner kan innehålla flera miljoner objekt med en rekommenderad maxstorlek på 16 TB. För att kunna identifiera ett objekt i detta träd så har varje objekt ett karaktärisktiskt namn (distinguished name). Syntaxen för de karaktäristiska namnen i Active Directory är den som definieras av LDAP standarden. Till exempel är det karaktäristiska namnet för administratörskontot i domänen exempel.se: cn=administrator,cn=users,dc=exempel,dc=se Som kan ses byggs det karaktäristiska namnet upp av olika attribut som namnger objekt eller containrar i Active Directory trädet. I exemplet ovan ligger objektet med CN Administrator i containern med CN Users. I tabell 7 visas de attribut som är definierade för LDAP version 3 samt vilka som har stöd i Active Directory. 14

20 1. Teoretisk grund Tabell 7: Attribut i karaktäristiska namn som definierade av LDAP (Desmond et al, 2008). Förkortning Attribut Stöd i Active Directory CN Allmänt namn Ja L Platsnamn Ja ST Delstat eller provinsnamn Nej O Organisationsnamn Ja OU Organisationsavdelningsnamn Ja C Landsnamn Ja STREET Gatuadress Nej DC Domänkomponent Ja UID Användar ID Nej För att unikt kunna identifiera en användare har varje användare två attribut: samaccountname och userprincipalname. samaccountname är användarens användarnamn och måste vara unikt inom den domän användaren tillhör. userprincipalname å sin sida ska unikt kunna identifiera användaren i hela skogen. En userprincipalname är av denna anledning skriven på samma format som en e-postadress, alltså användarnamn@domän.exempel.se. När en användare ska sökas upp i Active Directory bör ett av dessa attribut lämpligen användas. 15

21 2. En säkerhetslösning för Solr Kapitel 2 En säkerhetslösning för Solr Detta kapitel beskriver den studie jag gjort på hur dokumentsäkerhet bör utformas i Solr. Jag sätter upp villkor för en säker lösning och premisser för vad den rent konkret bör stödja. Prototypen som baseras på delar av denna studie redovisas i ett senare kapitel. En sökmotor fungerar som ett stödsystem till en eller flera redan befintliga datakällor. Dess syfte är att göra det enklare för en användare att hitta det hon letar efter. En datakälla kan vara till exempel ett innehållshanteringssystem, ett filsystem eller en databas. För säkerhetslösningen är det ointressant vilken typ datakällan är av, det intressanta är hur datakällan tillämpar sin säkerhetsmodell och det är sedan viktigt att sökmotorns säkerhetslösning gör detta på samma sätt. Eftersom sökmotorn innehåller all den information som i datakällan är skyddad skulle den ifall den inte skyddade denna data på ett korrekt sätt utgöra ett stort säkerhetshål. Sökmotorn kan skydda sina data enligt två olika strategier: den kan antingen lagra dokumentens säkerhetsinformation (Access Control Lists) och efterlikna säkerhetsmodellen i den befintliga datakällan, så kallad tidig bindning, eller så kan den fråga datakällan ifall en användare har rättigheter till ett visst dokument, så kallad sen bindning. Mängd A Z Mängd B A B Mängd Z C Sökmotor Säkerhetsinformation Datakälla Sökbegrepp Figur 13: Den mängd av filer som en sökmotor eller datakälla ger tillgång till. För att kunna diskutera begreppet dokumentsäkerhet i en sökmotor inför jag två begrepp: enkel dokumentsäkerhet och fullständig dokumentsäkerhet samt sätter upp villkor för dessa. Som illustreras i figur 13 kan sökmotorn och datakällan ses som svarta lådor. Givet en viss säkerhetsinformation (till exempel användarnamn och grupper) ger datakällan tillgång till en viss mängd filer (mängd B i figur 13). Ett specifikt sökbegrepp till sökmotorn ger även den ett resultat med en mängd filer (mängd A i figur 13). Snittet av dessa mängder är det resultat en skyddad sökmotor bör ge för denna datakälla, givet sökbegreppet och säkerhetsinformationen. Det finns dock anledningen att utvidga detta och ange den mängd av filer som fås från 16

22 2. En säkerhetslösning för Solr sökmotorn givet ett sökbegrepp och filtrerat på säkerhetsinformation som mängd C (figur 13). Med hjälp av dessa mängder sätter jag upp följande villkor: Villkor 1. För att sökmotorn ska anses ge enkel dokumentsäkerhet måste C A B. Villkor 2. För att sökmotorn ska anses ge fullständig dokumentsäkerhet måste C = A B. En sökmotor som uppfyller villkor 1 men inte villkor 2 säges enligt denna definition alltså ge enkel dokumentsäkerhet medan den som även uppfyller villkor 2 säges ge fullständig dokumentsäkerhet. Anledningen till att en sökmotor endast skulle ge enkel dokumentsäkerhet istället för fullständig dokumentsäkerhet är prestandakrav. Datakällan kan tillämpa en väldigt avancerad säkerhetsmodell som tar för lång tid att tillämpa i sökmotorn då en sökning sker. De fall som ger upphov till denna snäva filtrering kan oftast anses väldigt ovanliga. Rent konkret leder en avancerad säkerhetsmodell till att datakällans säkerhetsmodell inte kan efterliknas med ett booleskt uttryck som filter till en sökfråga. Detta kommer ges exempel på för NTFS som antingen kan skyddas med enkel eller fullständig dokumentsäkerhet. För att konkretisera denna studie kommer jag även sätta upp ett antal premisser som en implementation av en säkerhetslösning för Solr bör följa. Dessa premisser är inte som villkoren utformade för att säkerställa en säker lösning, istället är tanken att de tillsammans ska ge en så fullständig och flexibel lösning som möjligt. I kapitel 3 Analys av alternativa lösningar kommer alternativ till vissa av premisserna att läggas fram samt argument mot dessa. Premiss 1. Säkerhetslösningen bör implementeras i Solr som en Search Component. För att bibehålla den stora flexibilitet som Solr tillhandahåller bör säkerhetslösningen implementeras som en Search Component. Denna Search Component kommer fortsättningsvis att bli benämnd säkerhetskomponenten. Jag påminner om figur 5 över Solrs arkitektur där det framgår att en Request Handler kan ha flera Search Components kopplade till sig. Säkerhetskomponenten kopplas alltså till valfri Request Handler för att denna ska tillhandahålla dokumentsäkerhet. 2.1 Säkerhetskomponenten i Solr Premiss 2. Säkerhetskomponenten bör ha stöd för samtidig indexering av flera olika datakällor som sinsemellan kan bygga på olika säkerhetsmodeller. En stor fördel med ett fristående söksystem är att man kan indexera flera olika datakällor i samma system och därav göra det enkelt att söka simultant i dessa. Premiss 2 säger att säkerhetskomponenten bör ha stöd för samtidig indexering av flera olika datakällor. Säkerhetskomponenten ska därför kunna konfigureras med olika datakällor som också ska kunna använda sig av helt olika säkerhetsmodeller. I en sökning ska den sedan kunna avgöra vilka dokument som hör till vilken datakälla och således vilken säkerhetsmodell som bör tillämpas. Premiss 3. Säkerhetskomponenten bör ha stöd för tidig bindning. Det finns både för- och nackdelar med den bindningsmetod man använder sig av. Nackdelarna med respektive metod kan hittas i fördelarna hos den andra. Fördelarna med tidig bindning är: 1. Överlägsna prestanda över sen bindning. 2. Mindre datatrafik mellan söksystem och datakällor. 3. Mindre utnyttjande av resurser hos datakällor. Överlägsna prestanda fås genom att dokumentens ACL-information lagras som metadata till dokumenten i indexet och filtreringen därför kan göras i Solr med filter på användarens sökning. 17

23 2. En säkerhetslösning för Solr Mindre datatrafik blir det eftersom säkerhetskomponenten slipper fråga datakällan ifall användaren har behörighet till de dokument som ska visas. Av samma anledning kräver metoden även mindre utnyttjande av datakällans resurser. Den extra komplikationen med tidig bindning kommer i indexeringstid. Då ska ACLinformationen tillsammans med ett fördefinierat namn på datakällan tas in i Solr. Det är vitalt för säkerheten att ACL-informationen läses in korrekt, det vill säga spindeln måste på ett korrekt sätt bedöma vilka användare och grupper som får läsa filerna. Beroende på typ av datakälla måste detta göras på olika sätt, till exempel måste hela rättighetsträdet gås igenom i Polopoly. När sökning sedan sker går säkerhetskomponenten igenom alla förkonfigurerade datakällor och bildar ett filter som bara matchar de dokument som användaren har rätt att se. Premiss 4. Säkerhetskomponenten bör ha stöd för sen bindning. Trots de överlägsna prestanda som tidig bindning ger över sen bindning finns det tillfällen då en sen bindning krävs. För att göra säkerhetskomponenten mer flexibel bör den även ha stöd för sen bindning. Fördelar med sen bindning är: 1. Använder sig alltid av aktuella rättigheter i bedömningar. 2. Mindre benägenhet för felbedömningar av rättigheter än om söksystemet ska efterlikna datakällans säkerhetsmodell. 3. Fungerar för datakällor där det inte går att bedöma vilka som har rättigheter till ett objekt förrän man vet vem som efterfrågar det. Till exempel system som bygger på förmågor (capabilities). Sen bindning ger som sagt inte samma prestanda som tidig bindning men det är ändå viktigt att ha stöd för detta i en säkerhetslösning för Solr. En viktig aspekt är för system som har väldigt hög säkerhetsnivå, så att dessa ska kunna behålla ACL-kontrollen hos källorna. En annan är för att ha stöd för system som inte bygger sin säkerhetsstruktur på ACL:er. I den sena bindningen indexeras endast ett namn på datakällan som metadata till dokumenten. Sedan utgår säkerhetskomponenten från resultatet på användarens sökning så som den blir utan hänsyn till säkerhet. Med detta resultat som grund måste den sedan fråga datakällan för varje dokument som ska visas i resultatet ifall användaren har rättigheter att läsa dessa. Premiss 5. Säkerhetskomponenten bör ha stöd för att till en datakälla konfigurera en säkerhetsleverantör. Datakälla Säkerhetsleverantör Säkerhetsmodell Figur 14: Datakälla med säkerhetsleverantör och säkerhetsmodell som det ser ut i säkerhetskomponenten. Säkerhetskomponenten kommer att innehålla en lista med förkonfigurerade datakällor. I dessa datakällor finns det två centrala begrepp (se figur 14): säkerhetsleverantör och säkerhetsmodell. Alla datakällor kräver åtminstone att en av dessa är konfigurerade medan vissa kräver båda. Hur detta ser ut beror på datakällan. Till exempel krävs det att Active Directory som är en 18