Showing posts with label audit. Show all posts
Showing posts with label audit. Show all posts

Saturday 11 February 2023

Audit log retention in Dataverse

Overview: Audit data log retention is now fairly easy to implement in Dataverse, you can set whatever is audited and set the for how long duration easily.

Thoughts: As a simple version, I'd audit all changes into the Dataverse and set the retention to 7 years.  Now this could end up costing you a considerable amount of money so consider, do I need to audit everything, do I need to retain this long, can a use a long term storage retention approach.  There are a variety reasons for customising Datavervse data retention including: to comply with laws and potentially the need for litigation, to comply with industry standards/certification, and to keep a full history to understand why we have the current data position.
  
Ultimately, I need to identify/understand how to store audit history, clean up when no longer needed, ensure it is no affecting you live system performance, and can be retrieved by authorised people in the timeline required for each project or at an enterprise level.

If a system changes a lot and uses blobs, the audit history will be large and Dataverse is not necessarily the best place to store long term audit history.

Technical: Dataverse stores data in an Audit entity (table), the infrastructure has been changed in late 2022 to handle the audit data separately to allow for better non-functional requirements to available.

Sunday 25 January 2015

Auditing in SharePoint 2013

Overview: SharePoint provides excellent logging capabilities, to retrieve the auditing logs Site Settings > Site Collection Administration > Audit log reports.
Notes:
  • By default auditing is enabled in SharePoint.  PB: I think this statement if false, all the farms I review are not logging information in the audit logs.
  • Auditing is done at a Site Collection level.
  • Audit logs are kept for 30 days by default and can be change via the UI in the site collection and the clean up is controlled by CA.
  • Audit logs are stored within the content database, so watch the size of auditing logs.  They can take up considerable space in the content database so don't just audit everything and keep the logs endlessly.
  • Permissions changes, check-in/check-out, search queries, edits, document views (not SPO), ... can be audited.
  • Various reports can be downloaded into excel for slice and dice such as the Security settings audit log report.
  • Each logged event roughly takes up 2k. Calculating content database storage reqs:

Audit logs can be shipped to a central storage area and removed from the Content Database, this is ensential for large CDB's that require full auditing and performance is suffering.  AvePoint and Metalogix offer tools as part of their products that perform the audit log storage & removal from the CDB.  Also see Varonis.

References:
https://support.office.microsoft.com/en-us/article/View-audit-log-reports-b37c5869-1b47-4a82-a30d-ea20070fe527?CorrelationId=9139de6c-b33b-45c1-9cc2-d3958a88eab3&ui=en-US&rs=en-001&ad=US
http://sureshpydi.blogspot.co.uk/2013/05/audit-log-reports-in-sharepoint-2013.html
http://sharepoint-works.blogspot.co.uk/2013/07/audit-logging-in-sharepoint-2013.html
Centralised Auditing Product:
LepideAuditor Suite – SharePoint
http://www.lepide.com/sharepoint-audit/
LogBinder SP
https://www.ultimatewindowssecurity.com/sharepoint/logbindersp/Default.aspx

Sunday 2 February 2014

Audit and documenting a SharePoint on prem farm

Overview:  I have had and done several SharePoint infrastructure audits over the past few years.  These can vary from running through checklists of best practices to see what the customer setup has and finding out why they may of chosen to diverge. 

There is a lot of good tooling and checklists to help you audit your farm such as the built in Health analyser, central admin, PowerShell scripts and a great tool to help document your farm SPDocKitSetup from Acceleratio.

Tooling:
  • PowerShell
  • Health analyser
  • Central Admin
  • ULS logs and event logs
  • IIS (IIS RealTime Log Viewer)
  • Fiddler
  • SQL Management Studio, SQL profiler
  • Tool to audit and document your SharePoint farm: SPDocKitSetup
  • Third party tools like: DocAve and Metalogix (Ideara had a decent tool previously) can help audit and document your system.
The basic steps are:
  1. Document the farms topology;
  2. Verify versions and components installed;
  3. Compare MS recommendations to the farm settings, provide findings and allow the customer time to explain why these setting differ; and
  4. Monitoring, troubleshooting and performance.
Below are a few items to review:

SharePoint:
SharePoint Logs - I put these into my d drive
Multiple install accounts
List all customisations especially wsp and custom code
External Access - DMZ, network,

IIS:
Change the IIS default log location to a separate disk
Reclaim old IIS logs (Backup and remove from WFE's)
IIS RealTime Log Viewer - good tool for reading IIS logs

SQL basic checks:
I/O, CPU, Memory on the base database machine/s
MaxDop = 1
Initital mdf sizing and ldf sizing
ldf on fast disk, mdf of content db's on slowest disk (or just put it all on fast disk)
Backups

Maybe Reminders:
Remove all certificate files that are not needed (*.cer & *.pfx)
Ensure local account user name/passwords are changed & secure (I have a local admin account on my Windows template used to create all my VM's ensure this account is disabled or secured).

More Info:
http://nikpatel.net/2012/03/11/checklist-for-designing-and-implementing-sharepoint-2010-extranets-things-to-consider/
https://habaneroconsulting.com/insights/Do-you-need-a-SharePoint-infrastructure-audit
http://blog.muhimbi.com/2009/05/managing-sharepoints-audit.html
http://www.portalint.com/thoughts-on-sharepoint-audit/