Day three of the conference and I attended a comprehensive session on SharePoint security by Michael Noel. Now I wouldn’t normally heap praise on a session like this as security does tend to have the yawn factor and I for one struggle to keep awake on the subject of SP security so yes I did bring match sticks to keep my eyes open just in case..
Michael Noel comes from an infrastructure background so the session turned out to be quite interesting. A couple of key takeaways from the session were certainly to utilise the ‘Always On’ feature of SQL 2012 and the Transparent Data Encryption (TDE) features to encrypt your database backups. TDE is a very good feature available in both SQL 2008 and SQL 2012.
The key points from the session are detailed below in the five layers of SharePoint Security:
Layer 1 – Infrastructure Security: Use Kerberos instead of NTLM for numerous benefits like less hops for authentication. The search service account and content access account should be different as this will stop users seeing content they shouldn’t normally be allowed to see.
Later 2 – Data Security: Use Transparent Data Encryption (TDE) to encrypt the database. Note that the temp database will also be encrypted so you will need a separate SQL instance if only some of your content databases are required to be encrypted. If you use RBS then you can use bitlocker to encrypt the files on the file server. However, the data in memory is not encrypted.
Layer 3 – Transport Security: External or internal certificates are recommended if your SharePoint site is external facing. Be aware that there is a 20% overhead on your web servers when using certs. It is best practice to load balance Central Admin and use SSL. The traffic between your web servers and SQL is unencrypted so to encrypt this transport layer you will need to use IPSEC as it encrypts all packets between servers.
Layer 4 – Internet & SharePoint: SharePoint is not designed to be Internet facing without a degree of protection, so forefront unified access gateway (UAG) along with an ISO/Proxy server and your firewalls would need to be in place.
Layer 5 – Rights Management: AD RMS is a form of digital rights management (DRM) that is used to restrict activities on files.
I hope you found this interesting and you have some takeaways that you might use in your environment or even consider as an option in the future.
On the Tuesday of the SharePoint conference I attended an interesting session by Jason Kaczor on ‘Forensics for IT pro’s and administrators’. This session had a beware sign stamped all over it for developers as the session was mainly aimed at giving IT pro’s the knowledge and tools to check custom code (thoroughly!!) before it is deployed.
In a majority of cases issues with SharePoint is commonly caused by customisations (custom code). The issues that you are most likely to discover from bad custom code is memory leaks. Below are some bullet points on the tips and recommendations that I found useful from the session:
Only accept .wsp files (cabinet file) to deploy to your environment. Reject .exe, .msi and bat files.
If you have to deploy a msi (eg from a vendor) then unpack the file using msiexec or 7-zip and inspect the files. Deploy to your test environment first and look out for a licence file.
The wsp should contain a manifest.xml, which will list the solutions and features.
The solutions will have no version numbers, but the features do have version numbers as it is used to update/rollback a solution. Ensure the version number is an increment on the previous version.
If the wsp has no dll’s then the deployment will generally be safe. If you have multiple dll’s in your deployment then this is a potential risk to your environment.
Run SPDisposeCheck against the compiled code (DLL) which checks for potential memory leaks in the code.
If you have custom code already deployed to the GAC in your farm then you can use tools like windiff or winmerge to extract the structure of the files to a safe place for future reference.
The solution called ‘Lapointe.SharePoint2010.Automation.wsp’ by Gary Lapointe is a must have tool for any SharePoint environment. The solution runs a full audit of your SharePoint farm detailing all custom code deployed to it.
There are some very useful Static Analysis tools available for you to use to help troubleshoot and analyse custom code which I have listed below for you:
Fx Cop 10 – Performs static code analysis of .NET code.
Gendarme – Extensible rule-based tool to fine problems in .Net applications.
Cat.net – Is a binary code analysis tool for finding security vulnerabilities