Cloud Security Fundamentals

The Cloud Changes Everything (and Nothing)

Moving to the cloud does not eliminate security responsibilities — it redistributes them. Your data center may now live in Microsoft's or Amazon's facilities, but the data inside it is still your responsibility. The applications you configure, the users you manage, the permissions you grant — all of these remain firmly in your hands.

As IT support staff working with cloud services, you are often the first to create accounts, configure permissions, manage access, and troubleshoot issues. Understanding where your cloud provider's security responsibility ends and yours begins is essential to keeping your organization safe.

The Shared Responsibility Model

Every major cloud provider — Microsoft, AWS, Google — defines security as a shared responsibility between the provider and the customer. The provider secures the infrastructure; you secure what you put on it.

What the Cloud Provider Handles

• Physical security — Data center access controls, surveillance, environmental protections
• Network infrastructure — Core networking, DDoS protection at the infrastructure level
• Hardware — Servers, storage, compute infrastructure maintenance and patching
• Hypervisor — In IaaS, the provider manages the virtualization layer

What You Handle (Always)

• Data — Classification, encryption, access controls, backup, retention
• Identity and access — User accounts, passwords, MFA, permissions, conditional access
• Endpoints — Devices that connect to cloud services
• Account management — Who has access and what they can do

The Gray Area: It Depends on the Service Model

The key insight: the more "as a service" you consume, the more the provider manages — but you always own identity, access, and data.

Microsoft 365 Security Essentials

Most organizations use M365, and it is the cloud platform that IT support staff interact with most. Here are the security configurations that matter most.

1. Multi-Factor Authentication (MFA)

MFA should be enabled for every user, no exceptions. In Entra ID (formerly Azure AD):

• Security Defaults — Free, enables MFA for all users. A good starting point for small organizations.
• Conditional Access — More granular. Require MFA based on risk level, location, device state, or application. Requires Entra ID P1 licensing.
• Per-User MFA — Legacy approach. Use Security Defaults or Conditional Access instead.

Priority: Enable MFA for admin accounts first, then all users. An unprotected global admin account is the single highest risk in any M365 tenant.

2. Conditional Access Policies

Conditional access lets you create "if/then" rules for access decisions:

• Block legacy authentication — Older protocols (IMAP, POP3, SMTP AUTH) don't support MFA. Block them.
• Require MFA for admin roles — Always, from any location, on any device
• Require compliant devices — Only allow access from devices managed by Intune or meeting security requirements
• Block risky sign-ins — Use Entra ID Identity Protection to detect and block suspicious login patterns
• Restrict by location — Block sign-ins from countries where your organization has no employees

3. Admin Role Management

M365 has dozens of admin roles with varying levels of privilege:

• Global Administrator — Full control over the entire tenant. Limit this to 2-4 emergency accounts maximum.
• Use least-privilege roles — Instead of Global Admin, assign Exchange Admin, SharePoint Admin, or User Admin as needed
• Use PIM (Privileged Identity Management) — If you have Entra ID P2, PIM provides just-in-time admin access. Admins request activation of their role for a limited time, with approval and auditing.

4. External Sharing Controls

By default, SharePoint and OneDrive may allow sharing with anyone, including anonymous external users. Review and restrict:

• SharePoint external sharing — Set to "New and existing guests" or "Only people in your organization" depending on business needs
• Guest access in Teams — Control whether external users can be added to Teams channels
• Anonymous sharing links — Disable "Anyone with the link" sharing for sensitive content

Cloud Access Management

The Principle of Least Privilege in the Cloud

Everything you learned about least privilege on-premises applies to the cloud, amplified by the scale and speed of cloud environments:

• Cloud permissions are often overly broad by default — Azure's "Contributor" role grants write access to all resources in a subscription. AWS IAM policies frequently use wildcards (*) that grant far more access than intended.
• Service principals and managed identities need least privilege too — Applications and automation accounts should have only the permissions they need.
• Review permissions regularly — Cloud environments change fast. Monthly access reviews catch stale permissions.

Data Sovereignty and Residency

When your data lives in the cloud, it physically resides in data centers that may be located anywhere in the world. This matters for legal and regulatory reasons:

• Data residency — Some regulations require that certain data stay within specific geographic boundaries (e.g., GDPR for EU citizen data, Canadian PIPEDA for personal information)
• Data sovereignty — The laws of the country where data is stored may apply. If your data is in a US data center, it may be subject to US law enforcement requests.
• Multi-geo configurations — M365 and Azure allow you to specify where data is stored. Ensure your configuration aligns with regulatory requirements.

What IT Support Should Know

• Know which Azure region or M365 data center location your organization uses
• Understand if your organization has regulatory requirements for data residency
• Be cautious about features that may replicate data to other regions (backup, CDN, caching)

Common Cloud Misconfigurations

Cloud breaches are rarely caused by vulnerabilities in the cloud platform itself. They are caused by misconfigurations made by customers.

Top Cloud Security Mistakes

1. Storage buckets/blobs set to public access — The number one cause of cloud data leaks. Always verify that storage accounts are set to private access.
2. Overly permissive security groups/NSGs — Allowing 0.0.0.0/0 (all internet traffic) to access management ports (RDP 3389, SSH 22) is like leaving your front door open.
3. Disabled logging — Cloud audit logs are essential for detection and investigation. Never disable them to save costs.
4. Unencrypted data — Enable encryption at rest and in transit for all storage and databases.
5. Orphaned resources — Old VMs, expired service principals, test environments left running. They accumulate vulnerabilities and cost money.
6. No network segmentation — Putting everything in one virtual network with no access controls between tiers.
7. Missing backup and recovery — "The cloud is redundant" is not a backup strategy. Cloud protects against infrastructure failure, not against accidental deletion, ransomware, or misconfiguration.

Cloud Security Checklist for IT Support

Identity

• MFA enabled for all users (especially admins)
• Legacy authentication blocked via conditional access
• Global Admin limited to 2-4 accounts
• Admin roles follow least privilege
• Guest/external access policies reviewed

Data

• External sharing restricted appropriately
• Storage accounts set to private (not public)
• Encryption at rest enabled
• Data loss prevention (DLP) policies configured for sensitive data
• Backup and recovery tested

Monitoring

• Audit logging enabled (Entra ID sign-in logs, unified audit log)
• Alerts configured for suspicious activities
• Admin activity reviewed regularly
• Security score reviewed monthly (Microsoft Secure Score)

Key Takeaways

• The cloud is shared responsibility — The provider secures the infrastructure; you secure identity, access, and data
• MFA and blocking legacy auth are your highest-impact actions — Do these first in any M365 environment
• Least privilege applies in the cloud too — Default cloud permissions are often dangerously broad
• Misconfigurations cause cloud breaches, not platform vulnerabilities — Public storage, open ports, and disabled logging are the real threats
• Data sovereignty matters — Know where your data lives and what laws apply
• Cloud security is not optional or "handled by the provider" — If you configure it, you own its security