0

Say I have some secure documentation held in SharePoint.

Now say the SQL database/BLOB location is encrypted.

Enterprise Search is used to crawl this content and therefore the content is indexed. Is there anything in the index or search functionality that can expose in an unencrypted fashion the important information held within the documentation in question?

My opinion is no, since part of the index I believe stores pointers to the documentation! But I wanted to check if you had these components/files and you had the knowledge of the technical workings COULD the content be exposed?

1 Answer 1

0

It's not just a pointer to the file, the crawled content are stored as records within dedicated database(s) and contains key parts of the item (all the crawled properties) allowing it to be discovered through a search query. These crawled properties could lead to security breach if the permissions on the site / documents where not set properly (or if the security on the database itself is too weak, allowing someone to have a sneak peek inside).

All the Office:nn crawled properties are holding precious information that could be inadapted for someone to have access (even if it's just within a search result details and no real access to the secured item itself)

So if you have critical documents, the biggest concerns are how do you handle security on these libraries and their site ? What are you farm accounts ? Under which identity SharePoint is crawling your content ? Are you sure only relevant people have access to the list ? SharePoint will keep track of the security on each documents but that doesn't fix human misconfiguration (I've seen crawled account that are similar to app pool account, run a search query with elevated privilege by code for anyone and one can reach all documents...)

Oh, and don't forget that you can prevent crawling per library in extreme case :) I recently discovered military graded documents while searching for public SharePoint 2010/2013 sites using mobile view (view form page lockdown not activated and definitively huge issues regarding permissions on the libraries / network topoly / setup). I would not be the architect behind that site...

Edit : if you're the administrator / architect / lead developer / ... responsible for this, I would heavily recommend to carefully read this book from APress : http://www.apress.com/9781430234074. There are a bunch of book covering the subject but this is by far the best I purchased. Make sure that you read official ressources / guideline from a trusted authority (= not me!) to avoid any unforeseen results.

enter image description here

3
  • Firstly, thanks for your efforts and response. Let's ignore the risk with service accounts including crawl etc. I know that and the server needs to be secure. Imagine though the search databases were given to someone (this would never happen), or the query components directory. Is there enough in these two places to get to a documents content? Does a documents entire contents get put into a database? Wouldn't this be huge duplication? but if it does, can it be PUT back together.
    – Tezza
    Feb 1, 2013 at 9:48
  • You're welcome. The search database only contains surface information of the document not the actual document itself but if these documents are stored in SharePoint and you don't use RBS for SQL Server, the document themselves will be within the content database of the site collection hosting the documents. If someone can grab a copy of the search service databases, they will be able to get acces to the actual content database for sure :) Feb 1, 2013 at 11:19
  • RBS would be used hence the question :) I wanted to make sure the only place the documents were held in a usable fashion was at the source and source only. Thanks.
    – Tezza
    Feb 1, 2013 at 14:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.