Cloud and Remote Work Security | Free Cybersecurity Course: Protect Your Data, Devices and Business

What you'll learn

The shared responsibility model: what your cloud provider secures and what remains your job.
The most common cloud mistakes: open sharing links, missing MFA, over-permissioned apps and no logs.
Practical settings for Microsoft 365, Google Workspace and other SaaS tools.
Zero trust in plain English, and how VPNs compare with zero trust network access.
A secure setup for remote employees, from the laptop to the kitchen table.

Moving to the cloud doesn't move your security responsibilities to someone else. Providers like Microsoft, Google and Amazon secure their data centers and platforms very well, but you still decide who can sign in, what they can share and which apps get access to your data. Most cloud incidents trace back to those customer-side choices. This lesson explains where the line falls, fixes the most common misconfigurations and builds a secure setup for a team that works from home, coffee shops and airports.

3service models (IaaS, PaaS, SaaS), and in every one of them the customer is responsible for its data and user access

48%of breaches in Verizon's 2026 DBIR involved a third party, a reminder that SaaS vendors are part of your attack surface

0trust granted automatically in a zero trust model, whether you're in the office or at home

Know who secures what
Fix common cloud mistakes
Harden your SaaS
Apply zero trust
Secure remote workers

The shared responsibility model

Every cloud contract divides security duties between provider and customer. The split depends on the service model:

Layer	IaaS (virtual servers)	PaaS (app platforms)	SaaS (email, CRM, file sharing)
Physical data center, hardware, network	Provider	Provider	Provider
Operating system and patches	Customer	Provider	Provider
Application code and configuration	Customer	Customer	Provider (code) / customer (settings)
Identities, access and sharing settings	Customer	Customer	Customer
Your data and its classification	Customer	Customer	Customer
Devices used to access the service	Customer	Customer	Customer

Look at the last three rows: identities, data and devices are always yours. A provider can offer MFA, but only you can turn it on and require it. It can offer sharing controls, but only you can stop "anyone with the link" from being the default.

1. A company uses a SaaS file-sharing service. An employee shares a folder of contracts publicly by mistake. Under the shared responsibility model, whose responsibility was that setting?

The SaaS provider's, because it hosts the files
Nobody's; it's an accepted risk of cloud computing
The customer's, because sharing settings and user access are configured by the customer

In SaaS, the provider secures the platform, but the customer controls who has access and how data is shared. Default sharing policies and user training are customer duties.

The most common cloud mistakes

Open sharing links

Files set to "anyone with the link," which can be forwarded, indexed or guessed, and never expire.

Fix: default to internal sharing, require sign-in for external sharing and set link expiration.

Weak identity

Accounts without MFA, legacy sign-in methods that skip MFA, too many global admins.

Fix: require MFA for all, block legacy authentication, keep two or three admins.

Over-permissioned apps

Third-party apps granted "read all mail" or "access all files" when a user clicked Allow.

Fix: require admin approval for app connections and review connected apps quarterly.

No logs or backups

Audit logs off or kept briefly; the assumption that the provider backs up your data for you.

Fix: enable audit logs, extend retention, and add a SaaS backup for critical data.

On the backup point: SaaS providers keep their service running, but their retention and recycle-bin features aren't designed to restore everything after a mass deletion, a malicious insider or ransomware that syncs into the cloud. Read your provider's documentation on retention, and consider a third-party backup for email and files.

If you run IaaS (virtual servers and storage on AWS, Azure or Google Cloud), add three habits: never leave storage buckets publicly readable unless they're meant to be public websites, use roles with least privilege instead of long-lived access keys, and consider a cloud security posture management (CSPM) tool, which continuously checks your configuration against best practices.

Hardening your SaaS: a starter configuration

For Microsoft 365 and Google Workspace, CISA's Secure Cloud Business Applications (SCuBA) project publishes free secure configuration baselines. A small business can start with the most impactful settings:

MFA required for every user; phishing-resistant MFA for admins.
Legacy authentication protocols blocked.
External sharing limited to signed-in guests, with links that expire (for example, after 30 days).
Automatic forwarding of email to outside addresses blocked by default.
Users can't grant third-party apps access to company data without admin approval.
Audit logging turned on, with alerts for new admins, new forwarding rules and mass downloads.
Access allowed only from managed or compliant devices for sensitive apps, where your plan supports it.

Zero trust in plain English

Traditional networks worked like a castle: hard walls, a moat, and anyone inside was trusted. With cloud apps and remote work, there is no inside. Zero trust, described by NIST in SP 800-207, replaces location-based trust with three ideas:

Verify explicitly: every request is checked using the user's identity, MFA, the device's health and the context (location, time, sensitivity of the data).
Least privilege: each user and device gets access only to the specific apps and data it needs, for as long as it needs them.
Assume breach: design as if an attacker is already present: segment, monitor and limit how far any compromise can spread.

Traditional VPNConnect to the whole network

Access granted: Often the entire internal network once connected.
Device checks: ●●●●
Best for: Small teams with a few on-premises systems; always with MFA and prompt patching of the VPN device.

Familiar, broad

Zero trust network access (ZTNA)Connect to one app at a time

Access granted: Only the specific apps the user is allowed to reach.
Device checks: ●●●●
Best for: Organizations with cloud apps and remote staff that want to limit lateral movement.

Narrow, verified

2. Which statement best captures the zero trust approach?

No user or device is trusted by default; every access request is verified based on identity, device and context
Users on the office network are trusted; remote users are not
Trust is granted once a year after security training

Zero trust removes automatic trust based on network location. Each request is evaluated, and access is limited to what's needed.

Securing remote workers

A remote employee's security depends on four things: the device, the identity, the home network and the physical space.

Area	Practice	Why
Device	Company-managed laptop with MDM, automatic updates, encryption and EDR; no work on personal or family computers unless enrolled	IT can enforce settings, see alerts and wipe a lost device
Identity	SSO with MFA (passkeys where possible), separate admin accounts	Stolen passwords don't open company apps
Home network	Hardened router and WPA3 (lesson 5); work devices off the IoT network; phone hotspot instead of public Wi-Fi	Reduces exposure to compromised devices on the same network
Physical space	Screen lock when stepping away, privacy screens in public, no client documents visible on video calls, shred printouts	Shoulder surfing and stray paper are real leak paths
Communication	Approved apps for work chat and file sharing; verify unusual requests by phone	Remote teams are prime targets for impersonation scams

Case: a fully remote agency in Chicago

Lakeshore Creative, 18 employeesChicago, Illinois · fully remote, Google Workspace plus a dozen SaaS tools (a fictional example)

A client's security questionnaire asked about MFA, managed devices and data sharing. The agency's honest answers were embarrassing, so it spent a month fixing them: enforced MFA, shipped managed laptops to the seven people using personal machines, switched external sharing to "signed-in guests only, 30-day expiry," cleaned up old public links and removed 27 of 46 connected third-party apps.

Before

Staff with MFA11 of 18

Managed devices7 of 18

Public "anyone" links640

After one month

Staff with MFA18 of 18

Managed devices18 of 18

Public "anyone" links75

Public links down 88.3%, connected apps down 58.7%, and the client contract signed.

The 75 remaining public links are intentional: published portfolio pieces meant for anyone to see, reviewed every quarter.

3. An agency cuts public sharing links from 640 to 75. By what percentage did it reduce them?

11.7%
88.3%
565%

(640 − 75) ÷ 640 = 565 ÷ 640 = 0.883, or 88.3%. The 11.7% that remains (75 of 640) is the share of the original links still public.

Common mistakes

"It's in the cloud, so Microsoft or Google handles security."

They secure the platform; you configure identities, sharing, apps and logging.

Letting staff connect any app with "Sign in with Google" or Microsoft.

Require admin approval and review connected apps every quarter.

Remote employees working on family computers.

Provide managed devices, or enroll personal devices with clear rules before they touch company data.

One VPN account shared by the whole team.

Individual accounts with MFA, so access can be traced and removed person by person.

4. A new browser extension asks an employee to "read and change all your data on all websites" to help format emails. What's the safest policy?

Allow it if it has good reviews
Allow it but tell the employee to be careful
Block unapproved extensions and apps that request broad access, and use an approved alternative

Broad permissions let an extension read everything the browser sees, including cloud apps and passwords typed into pages. Approve extensions centrally and keep the list short.

Practice exercise

A Seattle accounting firm is hiring its first fully remote bookkeeper, who lives in Salt Lake City. The firm uses Microsoft 365, a cloud accounting platform and a tax application reachable only through the office VPN. Write the security setup checklist for her first day, organized by device, identity, network, data and people.

See solution

Device: company laptop shipped pre-enrolled in MDM, with full-disk encryption, automatic updates, EDR and a standard (non-admin) user account; screen lock after 5 minutes.
Identity: her own Microsoft 365 account with SSO into the accounting platform; MFA with a passkey or security key set up during a video call with IT; access granted from the bookkeeper role in the role matrix, nothing copied from another user.
Network: individual VPN account with MFA for the tax application (or ZTNA to that one app); guidance to check her home router against the lesson 5 checklist; phone hotspot instead of public Wi-Fi.
Data: client files only in the firm's approved storage, external sharing restricted to signed-in guests with expiry, no downloads to personal devices, a shredder or locked storage for any paper.
People: phishing and payment-verification training in week one, the incident contact number saved in her phone, and a scheduled access review at 90 days.

Summary

Cloud providers secure the platform; customers always own their data, identities, access settings and devices.
The common failures are open sharing links, missing MFA, over-permissioned apps and missing logs or backups.
CISA's SCuBA baselines and a short list of settings harden Microsoft 365 and Google Workspace.
Zero trust verifies every request by identity, device and context, and ZTNA narrows remote access to specific apps.
Remote work security combines managed devices, strong identity, a hardened home network and good physical habits.

Next lesson: Certifications (ISC2 CC, Security+) and Cybersecurity Careers. You'll compare the two most popular entry-level certifications in 2026, explore career paths and build a study plan.