Our series on Microsoft 365 administration continues as we turn our attention to SharePoint. SharePoint is the main storage location for all of your data in Microsoft 365. SharePoint, OneDrive, Microsoft Teams — all store their files here. Setting up SharePoint then becomes critical for most of your data. For the most part, we’re worried about getting the general security setting right. If you’re doing data compliance, your settings are going to carry through to all three services too.
Several areas affect your data storage security in the Microsoft 365 admin center, mostly around sharing permissions. Under “settings,” there are a couple. Under settings / organization-wide / SharePoint, you need to set who users can share with. In my tenant, I allow sharing with anyone, and it doesn’t require a sign-in. I do this because I need to provide anonymous links to files, like the calendar files for my regular webinars. However, I don’t make this the default. I configure it so that it is a positive choice to share something broadly. We’ll see that setting in a moment. This setting sets the maximum allowed sharing level, not the default level. That’s important to know when you’re making the decision on which setting to choose.
On the Security tab, in this same section, under Sharing, you need to choose where you will allow users to add new guests to your organization (if you allow this at all). When would they add a new guest? A new guest gets added every time you share data with someone outside of the organization. So, assuming that you’re going to allow any type of sharing, you will want to check this box.
SharePoint admin center
The SharePoint admin center is where we get to refine our security settings. Remember, the ones we just set represent the maximum allowed in the tenant. What we’re about to set now are the defaults.
Here we can set different levels for SharePoint and OneDrive if you need to. Using the drop-down under external sharing settings exposes the refinement settings. I select “guests must sign in using the same account to which sharing invitations are sent.” This does cause a few headaches, but I think it’s important to help you understand who your data has been shared with. And I suggest setting a reauthentication time limit of seven days. This gives them a week to work with the file that we’ve shared. They can have access longer but would be required to reauthenticate. We often encourage people we’ve shared data with to use the one-time passcode option to access the data. We don’t generally want to leave that data open for a long period. So here I say, yes, you can use the one-time password, but you’ll have to reauthenticate once a week if you choose that option.
Earlier I said that I don’t make the anonymous link the default choice. Well, here’s that setting. What you see here are the options that will be available to the users when they choose to share a file. As I have it configured here, when a user chooses to share a file, the default setting for that file is that it can be shared with only people within our organization. If they want to share it with someone else, we allow that, but they have to select to change the default option manually. I want to be sure that sharing externally is the intention and not accidental.
In that same theme, by default, sharing is set to view only. If they want to allow the recipient to edit the file, they will have to choose to change the default option.
Then I specify that the sharing link is good for 30 days, and then it will expire. That way, our data isn’t shared forever. This keeps data sharing to the minimum necessary to accomplish the task at hand while avoiding permission creep. Permission creep was always a problem on-premises, but here we have some control.
Further down, I set the maximum permission level for file and folders. And specify some other settings. We let the file and site owners see who has viewed the files. And we let SharePoint create shortened URLs for our shares.
In the SharePoint admin center, you’ll notice a section called access control. Access control contains several areas for security that should be configured.
First, you need to decide whether you’re going to allow unmanaged devices to have access at all. I consider using this setting here to be a hammer. If you use the hammer, users on devices that aren’t Azure AD joined will be denied access. If they are denied, they get the generic “this content isn’t available” message from SharePoint. It doesn’t let them know that it’s because they aren’t on a safe device. Since most of my clients are not Azure AD joined but instead are Azure AD registered, I prefer to create my own conditional access policy to manage access control. Conditional access policies in Azure AD allow you much more fine-grained control over access, such as requiring compliance, MFA, and modern app usage.
Be careful with the Sign out inactive users setting here. If a user is active in Outlook but not in SharePoint or OneDrive, this setting will log them out across Microsoft 365, not just the specific apps. And moving a mouse around isn’t considered active. They have to be actively using the application to keep the session alive. But note that these settings won’t apply to anyone who is domain joined or on a compliant device.
Once you’ve taken care of these very basic security settings, you’re ready to begin to create sites, pages, lists, and libraries and bring your data into SharePoint. While you can’t migrate your old SharePoint sites, Microsoft has at least provided some good tools for getting the data migrated over.
In the admin center quickstart guide, you’ll find a whole range of tools for bringing data from on-premises file shares, from Gmail, SharePoint, exchange, all with ready to use guidance and tools. Many people use third-party tools, but you should really look at what Microsoft offers built-in because they are quite decent. For our SMB clients, we find them perfectly sufficient. The amazing thing to me is always how fast the migration goes. We’ve been moving people into Microsoft’s cloud since 2008. In the last couple of years, Microsoft has performed some behind the scenes magic that lets data and email migrate really fast.
It doesn’t take a whole lot to get SharePoint security set up initially. These items will form the foundation of your security structure. From here, depending on your design, you’ll set data access based on team membership in Microsoft Teams, public or private channel, and team membership and on group access to sites and pages in SharePoint using Azure AD groups. Security gets extremely fine-grained in those applications, even layering on data loss prevention, retention, compliance, and privacy. All of those features retain their fidelity across the applications now. But it all starts with the settings we just reviewed. Get these settings right, and everything else down the line will go that much smoother. Security can be tricky, but starting with a solid foundation will let you build it right.
Featured image: Shutterstock