Showing posts with label CAS. Show all posts
Showing posts with label CAS. Show all posts

Tuesday 12 November 2019

Microsoft Information Protection


Check out my earlier Post on AIP (feb 2019)

End-to-end life-cycle for encrypting files using Azure Information Protection (AIP)


Use "Unified Labeling" to create labels



Note: Encrypting stops SharePoint being able to look into the content of the file.  The labels and name are still search but not the content of the file.  eDiscovery, Search, co-authoring don't work on AIP encrypted documents.

Cloud App Security (MCAS) Screen Shot


Sunday 18 November 2018

Securing SharePoint O365

Microsoft outline how they treat access to your company data, how your data is kept secure and audit and availability, read this post.  The information below notes possible settings and configuration to secure 0365.

Azure AD is the key, ensure auth is 100%.  e.g. MFA for some or all accounts.  Use the "Identity Secure Score" to check possible problems.  Consider Microsoft Authenticator for MFA.

O365 Settings use:
  1. Secure Score - Overview of my tenant settings and how they should be set.  Check my tenant again set MS best practices for O365. 
  2. Validate setting meet governance and are not merely defaults.
  3. Review SPO audit logs - ensure it is turned on (default is to have it turned off).
  4. Security and Compliance Dashboard - Good email checker/analysis.  Low value for SPO.
Cloud App Security (CAS) - service looks for security on O365 tenants, improving constantly.  CAS Overview.  Add-on or included in E5 plans.

Office 365 Advanced Threat Protection (ATP) - service to identify threats.  "ATP analyzes content that's shared and applies threat intelligence and analysis to identify sophisticated threats.", Microsoft.

To manage document use IRM on SPO and AIP on documents.

"Azure Active Directory Identity Protection is a feature of the Azure AD Premium P2 edition that enables you to 1) Detect potential vulnerabilities affecting your organization’s identities 2)
Configure automated responses to detected suspicious actions that are related to your organization’s identities 3) Investigate suspicious incidents and take appropriate action to resolve them".  More info.


Thursday 22 July 2010

Deploying to GAC vs bin folder in SP 2010

Problem: Do we deploy our to the GAC or the bin directory.

Answer: It depends on what the dll is, who needs to use it and is the SharePoint farm dedicated. You need to understand Code Access Security (CAS). Key point is dlls in the GAC (Global Assembly Cache) have full privileges. dll's in the bin have restricted privileges. You can change the level of permissions for dll's in the bin using CAS policies. SharePoint has 2 policys you can use by default: WSS_Minimal or WSS_Medium (same options as in MOSS). You can also use ASP.NET's policies, there are about 5 of these policies in .NET and the highest level is the "Full Trust" CAS policy. You can also create your own policy. Change the CAS relating to you dll's in the bin via your applications web.config.

Only code that runs in the IIS workprocess can be placed in the bin.  Deploying to the bin minimises permissios but certain tasks such as timer jobs, workflows, service applications and event receivers only work in the GAC.  Deploying to the GAC allows for multiple versions of the dll to exist in the GAC provided versioning is used.  Bin deployment can't have multiple versions.

Note on Sandboxed solutions - runs is the "Microsoft SharePoint Sandboxed Code Service", sandboxed solutions have restricted rights to what it can do. It can permorm basic SP Server side OM's unde the SPSite (Site collection) object under the current SPSite which makes sense. Sandboxed code is deployed to the solutions gallery under the current SPSite. You can also use sandboxed solutions with code proxyies to achieve higher rights operations.  So as you can see sandboxed solutions do not go into the GAC or the bin and CAS is not an issue.  Real option is between GAC + using a Sandbox solution.

Sandbox solutions are good in restricted high usage environments as they allow SharePoint Administrators to validate (manually and via solution validators) the code being uploaded.  Developers are limited in what they can do to the environment.  The counter stop inefficient code once the threshold has been passed.  Administrators can monitor sandboxed solutions to easily identify poorly performing code.

My general rule is: Deploy my custom code to the GAC except if it's not trusted i.e. 3rd party code or there is a business reason/policy not to. It makes dev easier but is not ideal in that best practice decitates that you should apply the minimal levels of security permissions to your code.
Additional Info: Microsoft SharePoint Team Blog on application development.
Great blog on sandboxed solutions