Security Engineering: Access Control and Data Protection

Table of Contents

• Module 1: Understanding Identity
  • Identification, Authentication, and the Kerberos Protocol
  • Multi-Factor Authentication and Passwordless Methods
  • Authorization and OAuth 2.0
  • Federated Identity and Single Sign-On
  • The OpenID Connect and OAuth 2.0 Workflow
  • Identity-Based Attacks and Mitigations
• Module 2: Managing Access
  • Access Control Types
  • Identity and Access Management Lifecycle and Platforms
  • Demo: Managing AWS IAM Users, Groups, and Policies
• Module 3: Protecting Data
  • Encryption Fundamentals and States of Data
  • Asymmetric Encryption and Public Key Infrastructure
  • Data Integrity, Hashing, and Digital Signatures
  • Cloud Key and Secrets Management
• Module 4: Data Security
  • Data Exfiltration and Data Loss Prevention
  • Data Storage Security
  • Database Security and Compliance
  • Demo: Enabling Transparent Data Encryption on Azure SQL Database
• Summary

Module 1: Understanding Identity

Identification, Authentication, and the Kerberos Protocol

Before any access decision can be made, a system must know who is asking. This begins with identification, the process of presenting a claim to an identity. In the physical world this looks like presenting a driver’s license; in an information system, it is the equivalent of typing a username at a login page. The entity making this claim — most often a human user, but potentially a system, service, or application — is called a principal.

Once a principal has identified itself, the relying party must verify that claim through authentication: confirming that the presented identity and credentials are valid, and that the principal truly is who or what it claims to be.

flowchart LR
    A[Principal] -->|1. Presents claim| B[Identification]
    B -->|2. Verify credentials| C[Authentication]
    C -->|3. Check permissions| D[Authorization]
    D -->|4. Grant/deny| E[Access to Resource]

Kerberos is the primary authentication protocol used within Windows Server Active Directory. Its mechanics are easiest to understand through a theme park analogy:

• The Key Distribution Center (KDC) sits at the front gate. It acts both as the authentication server (AS), which verifies a principal’s identity, and as the ticket-granting server (TGS), which issues service tickets once a principal already holds a ticket-granting ticket (TGT).
• Before entering the park, the user authenticates to the KDC and is issued a ticket-granting ticket. This grants entry to the park itself but not to any individual ride.
• To ride the roller coaster, the user must present their TGT to the KDC and request a service ticket specific to that ride.
• The user then presents the service ticket to the “gatekeeper” of the ride — the service server — which performs service validation, checking the ticket’s validity before granting access to the service.
• To go on a different ride (the boat voyage), the user again presents the TGT to the KDC, obtains a new, unique service ticket for that ride, and the service server performs service validation again before granting access.

sequenceDiagram
    participant U as User (Principal)
    participant KDC as KDC (AS + TGS)
    participant SS as Service Server (Ride)

    U->>KDC: Authenticate (prove identity)
    KDC-->>U: Ticket-Granting Ticket (TGT)
    U->>KDC: Request service ticket (present TGT)
    KDC-->>U: Service Ticket (for Roller Coaster)
    U->>SS: Present Service Ticket
    SS->>SS: Service validation
    SS-->>U: Access granted (ride the coaster)
    U->>KDC: Request new service ticket (present TGT, for Boat Voyage)
    KDC-->>U: Service Ticket (for Boat Voyage)
    U->>SS: Present Service Ticket
    SS-->>U: Access granted (boat voyage)

The key insight is that the KDC is only ever presented with full credentials once. Every subsequent access to an individual service is authorized through short-lived, service-specific tickets, minimizing the exposure of the principal’s original credentials.

Multi-Factor Authentication and Passwordless Methods

Multi-factor authentication (MFA) requires a principal to present two or more distinct authentication factors before being authenticated. Combining factors dramatically reduces the risk of identity attacks, since an attacker would need to compromise multiple, independent proofs of identity.

Using two or more of these factors together makes it highly unlikely that a malicious actor possesses all of them simultaneously.

One-time passwords (OTPs) are single-use credentials that can only be used once during authentication. They can be delivered via email, or via SMS text message to a mobile device — although SMS delivery is discouraged because SMS is a legacy protocol and mobile SIM cloning makes this delivery method vulnerable. A stronger alternative is a randomly-generated token from a hardware token device, or a software-based token generator such as Microsoft Authenticator or Google Authenticator.

Passwordless authentication provides one-time access similar to an OTP, but without any password or code being set for the principal to enter. Common passwordless methods include:

• Magic links — a link delivered via email or messaging platform that authenticates the principal once opened.
• Mobile authenticator apps — such as Microsoft Authenticator, where the principal selects a number displayed at the start of the authentication process, often in combination with a biometric factor.
• Biometric readers — fingerprint, iris, or facial recognition, either built into the device (such as Touch ID on a MacBook) or via a dedicated FIDO2 hardware device.

mindmap
  root((Passwordless Authentication))
    Magic Links
      Emailed or messaged
      Authenticates on open
    Authenticator Apps
      Number matching
      Biometric confirmation
    Biometric Hardware
      Built-in device sensor
      Touch ID
    FIDO2 Devices
      YubiKey
      CTAP
      WebAuthn API
    Passkeys
      Software-based
      Public/private key pair
      No physical hardware required

FIDO2 (Fast IDentity Online, version 2) is an open standard built around passwordless authentication. A user authenticates using a biometric device, or by inserting/tapping a device such as a YubiKey against a computer or smartphone, typically followed by a biometric confirmation step. FIDO2 devices communicate with operating systems and browsers through the Client to Authenticator Protocol (CTAP). Once connected, the WebAuthn API — supported by browsers such as Firefox, Safari, and Chromium-based browsers — performs authentication using public key cryptography against WebAuthn-supporting servers.

Passkeys are conceptually similar to FIDO2 devices: they rely on public key infrastructure where the private key remains on the client and the authentication server uses the corresponding public key to verify it. The key difference is that passkeys are software-based and therefore require no physical hardware.

Authorization and OAuth 2.0

Where authentication verifies who a principal is, authorization verifies that a principal is permitted to access a particular service, resource, or system, and to perform a particular action against it. A principal authorized to access a file server may still lack permission to delete a file from it, because that specific action was never granted.

OAuth 2.0 (Open Authorization 2.0), defined in RFC 6749, is one of the most widely used authorization protocols. It describes how third-party applications can be granted access to a principal’s resources without being exposed to that principal’s credentials. OAuth 2.0 fully replaced OAuth 1.0, which shares little in common with the current version.

OAuth 2.0 revolves around tokens:

• Access tokens grant access to protected resources.
  • Bearer tokens can be used by any entity that possesses them.
  • Sender-constrained tokens are bound to a specific client and cannot be used by another party even if intercepted.
• Refresh tokens are longer-lived tokens used to obtain new access tokens without requiring the principal to reauthenticate.

Although OAuth 2.0 has technical capability to be misused for authentication, it should be used strictly for authorization. Misconfigured deployment of OAuth 2.0 for authentication purposes can introduce vulnerabilities such as insecure session management. Instead, security engineers should pair OpenID Connect (OIDC) for authentication with OAuth 2.0 for authorization.

Federated Identity and Single Sign-On

Federated identity is the use of a single identity across multiple, separate, and independent systems outside of an organization’s own domain — for example, third-party SaaS applications outside of an Active Directory domain.

Federated identity relies on identity providers (IdPs), which sit between a principal and the service provider the principal wants to access. The principal authenticates with the identity provider first, and only then is able to communicate with the service provider.

• An identity provider can be on-premises (such as an Active Directory domain controller).
• An identity provider can be an external, typically cloud-based service offering Identity as a Service (IDaaS) — examples include Okta and Microsoft Entra ID.

The capability enabling access to multiple systems through a single authentication event is single sign-on (SSO): the principal authenticates once to an identity provider, which then authenticates them transparently to multiple other systems and services.

flowchart TB
    P[Principal] -->|Authenticates once| IdP[Identity Provider]
    IdP -->|Trust relationship| SP1[Service Provider 1]
    IdP -->|Trust relationship| SP2[Service Provider 2]
    IdP -->|Trust relationship| SP3[Service Provider 3]
    P -.->|Access without re-authenticating| SP1
    P -.->|Access without re-authenticating| SP2
    P -.->|Access without re-authenticating| SP3

When SSO involves Active Directory domain controllers acting as the identity provider, the Security Assertion Markup Language (SAML) is the standard of choice for exchanging authentication and authorization data between IdP and service provider. SAML supports multiple transport mechanisms:

• HTTP — used for client web browser SSO logins.
• SOAP — used for back-channel communication, such as facilitating a single logout across all applications in use, and for attribute queries about an identity and its permissions.

A more modern SSO protocol, widely adopted by mobile and web applications, is OpenID Connect. It is highly versatile, leveraging RESTful APIs for communication and JSON for data formatting. The familiar “sign up with your social media account” login screen is typically backed by OpenID Connect.

The OpenID Connect and OAuth 2.0 Workflow

The combined OpenID Connect (authentication) and OAuth 2.0 (authorization) workflow proceeds as follows:

1. The user attempts to access a protected resource through the client application.
2. Since the resource is protected, the client app redirects the user to the authorization server, sending an authorization request containing:
   • client_id — identifies the client application.
   • redirect_uri — specifies where the response should be sent.
   • response_type — typically code, meaning the client expects an authorization code in response.
   • scope — defines the level of access requested; for OpenID Connect this typically includes the value openid.
3. The authorization server prompts the user to sign in, and may prompt them to approve specific requested permissions (such as access to contacts).
4. The authorization server sends the user an authorization code.
5. The client application forwards this code, along with its client_id, client_secret, and redirect_uri, as part of a token request.
6. The authorization server validates the token request and responds with an access token (called an ID token in OpenID Connect), and optionally a refresh token.
7. The client application includes the access token in its resource request to the resource server.
8. The resource server verifies the token and, if valid, grants access.
9. The user can now interact with the resource server through the client application.

sequenceDiagram
    participant U as User
    participant C as Client Application
    participant A as Authorization Server
    participant R as Resource Server

    U->>C: Request protected resource
    C->>A: Authorization request (client_id, redirect_uri, response_type=code, scope=openid)
    A->>U: Prompt for sign-in / consent
    U->>A: Provide credentials / approve
    A-->>C: Authorization code
    C->>A: Token request (code, client_id, client_secret, redirect_uri)
    A-->>C: ID Token / Access Token (+ optional Refresh Token)
    C->>R: Resource request (access token)
    R->>R: Verify access token
    R-->>C: Protected resource data
    C-->>U: Deliver resource / render UI

Identity-Based Attacks and Mitigations

As security engineers, we need to recognize and mitigate the most common categories of identity attacks:

mindmap
  root((Identity Attacks))
    Brute Force
      Repeated password guessing
      Account lockout thresholds
      IDS/IPS alerting
    Spoofing and Impersonation
      IP address spoofing
      Account impersonation
      Email phishing
      SPF / DKIM / DMARC
      MFA
      PKI-based authentication
    Broken Authentication
      Improper session management
      Sessions that never expire
      Reusable/replayable cookies and tokens
    Credential Stuffing
      Reused breached credentials
      Password managers
      Passwordless authentication

Brute force attacks involve a hacker repeatedly guessing a password until the correct one is found. Effective controls include:

• Account lockout thresholds that disable an account and require manual administrative re-enablement.
• Intrusion prevention and detection systems (such as Snort) that alert on repeated password attempts:

alert tcp any any -> any 3389 (msg:"Possible RDP Brute Force Attempt"; \
  flow:to_server,established; \
  threshold:type threshold, track by_src, count 5, seconds 60; \
  sid:1000001; rev:1;)

This example Snort rule alerts on Remote Desktop Protocol brute-force attempts from the same source IP address after five attempts have been made within 60 seconds.

Spoofing and impersonation attacks involve a threat actor fraudulently claiming the identity of another principal or entity — whether an IP address, a user account, or, most commonly and successfully, via email phishing. Email security can be strengthened using:

• Sender Policy Framework (SPF) — prevents attackers from sending email on behalf of your domain.
• DomainKeys Identified Mail (DKIM) — verifies the integrity and authenticity of an email.
• Domain-based Message Authentication, Reporting and Conformance (DMARC) — reports on failed SPF/DKIM checks and defines how to handle them.

example.com.   IN TXT "v=spf1 include:_spf.example.com -all"
selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=<public-key>"
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Additional mitigations include multi-factor authentication and PKI certificate-based authentication.

Broken authentication frequently stems from improper session management: sessions that do not expire within a reasonable time, or poorly managed cookies/tokens that can be reused or replayed by an attacker.

Credential stuffing has become increasingly prevalent as data breaches proliferate. When a web application is breached, attackers take the exposed credentials and attempt to reuse them across many other sites, exploiting poor password hygiene. Mitigations include leveraging passwordless authentication where possible, and requiring users to store unique passwords per site inside a password manager.

Module 2: Managing Access

Access Control Types

Building on authorization, access refers to the level of interaction a principal has with a service, resource, or system, typically governed by a list or policy.

• Permissions are assigned to individual principals or groups and permit specific actions (read, write, execute, modify, delete).
• Privileges encompass a set of permissions but pertain more broadly to the authority a principal or group holds over an entire system, resource, or service — for example, domain administrator accounts in Windows Server or super user/root accounts in Linux distributions.

Several access control types are available to security engineers:

flowchart TD
    AC[Access Control Types] --> DAC[Discretionary Access Control]
    AC --> MAC[Mandatory Access Control]
    AC --> RBAC[Role-Based Access Control]
    AC --> FGAC[Fine-Grained Access Control]
    FGAC --> ABAC[Attribute-Based Access Control - policy driven, static]
    FGAC --> DYN[Dynamic Access Control - real-time, adaptive]

    DAC -->|Risk| R1[Human error, lingering permissions, does not scale]
    MAC -->|Basis| R2[Classification levels: Top Secret, Secret, Unclassified]
    RBAC -->|Basis| R3[Job role / group membership - least privilege]

• Discretionary Access Control (DAC) — access is controlled at the discretion of an individual. This does not scale well: with one individual (or small group) managing access across thousands of principals, there is a high risk of human error, lingering permissions, and over- or under-provisioned access.
• Mandatory Access Control (MAC) — access is based on unchanging or semi-permanent characteristics such as classification levels (e.g., Top Secret, Secret, Unclassified). A principal cleared at the Secret level can access Secret and Unclassified information, but never Top Secret, since it sits above their clearance. MAC is well-suited to classifying systems and resources, but can be too broad for defining individual access levels.
• Role-Based Access Control (RBAC) — access is defined by a person’s role and job duties rather than by clearance level or administrator discretion. RBAC directly supports the principle of least privilege, since access is granted based only on the minimum level required for a given role.
• Fine-grained access control — provides more refined control by evaluating attributes related to the principal and/or the resource. This can be done manually via tags (similar to DAC), or through policy enforcement, where access decisions are computed from a principal’s attributes (role, resource, other conditions).
  • Attribute-Based Access Control (ABAC) leverages predefined, relatively static policies.
  • Dynamic access control makes real-time adjustments based on changing conditions and attributes such as role, location, or device being used — making it more adaptive than ABAC.

A concrete RBAC example: users Ash and Brad each belong to different groups (roles). Ash belongs to the Marketing group and can access marketing material; Brad belongs to the Developers group and can access development code. Both belong to the Database Admins group and can read/manage cloud databases. Because Ash is not in Developers, they cannot access development code; because Brad is not in Marketing, he cannot access marketing material.

flowchart LR
    Ash((Ash)) --> Marketing[Marketing Group]
    Ash --> DBA[Database Admins Group]
    Brad((Brad)) --> Dev[Developers Group]
    Brad --> DBA

    Marketing --> M1[Marketing Media]
    Dev --> D1[Development Code]
    DBA --> D2[Cloud Databases - Read/Manage]

Identity and Access Management Lifecycle and Platforms

Identity and Access Management (IAM) is the management of identities and their access rights, applying the principle of least privilege while providing the appropriate level of permissions — strengthening security and supporting regulatory compliance.

Identity management follows a lifecycle:

flowchart LR
    P[Provisioning] --> Rev[Periodic Review]
    Rev -->|Update access as needed| Rev
    Rev --> Rvk[Revocation]
    P -->|Account created, least-privilege access granted| P
    Rvk -->|Account retired, e.g., employee departs| End[End of Lifecycle]

1. Provisioning — an account is created, registered, and granted only the access necessary for its job role.
2. Periodic review — accounts are reviewed to confirm they are neither over- nor under-privileged, with access updated accordingly. Many compliance frameworks (such as PCI DSS) mandate account audits, and discovery of overprivileged accounts becomes an audit finding.
3. Revocation — accounts are retired once no longer needed, such as when an employee’s employment ends. Failing to revoke access promptly has historically allowed former employees to log back in and perform malicious actions.

On-premises: Windows Server Active Directory is the typical platform for managing identities and access. Its hierarchy is:

flowchart TD
    Forest[Forest] --> Domain1[Domain]
    Domain1 --> OU1[Organizational Unit]
    OU1 --> Groups[Groups]
    OU1 --> Computers[Computers]
    OU1 --> Users[Users]
    OU1 --> GPO[Group Policy Objects]
    GPO -->|Defines access, permissions, privileges| Users

Access management in Active Directory is largely handled through Group Policy Objects (GPOs), which define the access controls applied to identities and systems. GPOs can be linked at the forest level, but this is strongly discouraged since the scope is too broad. It is preferable to link GPOs at the domain or organizational unit (OU) level, using Group Policy filtering to apply the appropriate controls based on group/role — ensuring end users are affected by these controls regardless of which system they log into.

In the cloud, providers such as Microsoft Azure and AWS offer their own IAM services:

Conditional access is a form of dynamic access control that grants access based on conditions such as user, location, and resource — available in Entra ID.

Finally, two related but distinct disciplines:

flowchart LR
    subgraph PAM[Privileged Access Management]
        direction TB
        PAM1[Manages and monitors access TO sensitive resources/servers/systems]
        PAM2[Controls how privileged accounts, e.g. domain admins, are used]
    end
    subgraph PIM[Privileged Identity Management]
        direction TB
        PIM1[Manages privileged IDENTITIES and accounts themselves]
        PIM2[Enforces least privilege via temporary and conditional access]
    end

• Privileged Access Management (PAM) focuses on managing and monitoring access to sensitive resources, servers, and systems, and how privileged accounts (e.g., domain administrators) are used against them.
• Privileged Identity Management (PIM) focuses on managing the privileged identities and accounts themselves, keeping them aligned with least privilege through capabilities like temporary and conditional access.

Demo: Managing AWS IAM Users, Groups, and Policies

This walkthrough demonstrates creating a user, placing them in a group, and attaching an AWS-managed IAM policy that follows the principle of least privilege.

1. Navigate to the AWS Console search bar, type IAM, and select it to open the IAM Dashboard (users, groups, roles, policies).
2. Select Users in the left navigation, then Create user. Enter the user’s name, click Next twice, then Create user.
3. Select User groups in the left navigation, then Create group.
4. In the group creation screen, check the box next to the newly created user (e.g., TestUser) to add them to the group.
5. Name the group — in this example, QDev (for Amazon Q Developer access).
6. To follow the principle of least privilege and AWS best practices, attach an AWS managed policy: under Attach permission policies, search for QDev and select the pre-existing Amazon Q Developer Access managed policy.
7. Click Create user group.
8. Drill into the QDev group. TestUser now appears as a member. Under Permissions, select the attached policy to review it — it grants:
   • Read access to the Cloud Control API.
   • Read/write access to the Amazon Q service.
   • Limited write access to Amazon STS.

Reviewing the underlying JSON policy document reveals the following structure:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAmazonQDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "q:StartConversation",
        "q:SendMessage",
        "q:GetConversation",
        "q:ListConversations",
        "q:PassRequest",
        "q:StartTroubleshootingAnalysis",
        "q:StartTroubleshootingResolutionExplanation",
        "q:GetTroubleshootingResults"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowCloudControlReadAccess",
      "Effect": "Allow",
      "Action": [
        "cloudformation:GetResource",
        "cloudformation:ListResources"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowSetTrustedIdentity",
      "Effect": "Allow",
      "Action": [
        "sts:SetContext"
      ],
      "Resource": "arn:aws:sts::*:assumed-role/*/${aws:username}"
    }
  ]
}

• Version describes which AWS policy syntax version is in use (the most recent version, 2012-10-17).
• Statement is a list of individual permission statements, each with a unique Sid (statement identifier), an Effect (Allow or Deny), the Action(s) permitted, and the Resource(s) the permission applies to.
• The AllowAmazonQDeveloperAccess statement allows the listed Amazon Q actions against all (*) Amazon Q resources.
• The AllowCloudControlReadAccess statement allows read-only CloudFormation resource actions against all CloudFormation resources.
• The AllowSetTrustedIdentity statement allows the STS SetContext action, but scoped only to STS resources related to the current user.

This demonstrates the full loop: creating an identity, placing it into a group, and attaching a managed IAM policy — ensuring the identity only has the access necessary to perform its job role.

Module 3: Protecting Data

Encryption Fundamentals and States of Data

Encryption protects the confidentiality of data by transforming plaintext into ciphertext using a cryptographic key. Anyone intercepting the ciphertext cannot read it without the corresponding decryption key; only parties in possession of that key can decrypt the ciphertext back into plaintext.

Before going further, it is important to distinguish the states of data:

Symmetric encryption uses the same cryptographic key to both encrypt and decrypt data. In the classic example, Bob encrypts a confidential message using a shared key and sends it to Roger, who uses that same key to decrypt it back into plaintext.

sequenceDiagram
    participant Bob
    participant Roger
    Note over Bob,Roger: Both possess the same symmetric key (K)
    Bob->>Bob: Encrypt(message, K) -> Ciphertext
    Bob->>Roger: Send Ciphertext
    Roger->>Roger: Decrypt(Ciphertext, K) -> message

The Advanced Encryption Standard (AES) is one of the most widely used and secure symmetric block ciphers, established by NIST in 2001. AES supports key lengths of 128, 192, and 256 bits, with data processed in 128-bit blocks. AES is FIPS 197 compliant, making it suitable for use by the US government and military (Triple DES and Skipjack are also FIPS 197 approved, but AES is strongly favored today).

Common use cases for symmetric encryption:

• Data at rest: Windows BitLocker and macOS FileVault both use variations of AES.
• Data in transit: Transport Layer Security (TLS) uses symmetric encryption after its handshake exchanges the symmetric key, since symmetric operations are fast enough for low-latency web communication.
• VPN tunnels: many VPNs use symmetric encryption via a shared secret established after the Internet Key Exchange (IKE) phase.
• End-to-end messaging: platforms like WhatsApp and iMessage use symmetric encryption for speed once a key exchange (similar to IPsec VPN tunnels) has occurred.

As a general rule: whenever fast encryption is needed, symmetric encryption should be the choice.

Asymmetric Encryption and Public Key Infrastructure

Asymmetric encryption uses a key pair: a private key, never shared with anyone other than its owner, and a public key, which can be freely distributed. The public key encrypts data; only the corresponding private key can decrypt it.

sequenceDiagram
    participant Alice
    participant Bob
    Note over Bob: Bob holds Private Key (never shared)
    Note over Alice: Alice holds Bob's Public Key (freely shared)
    Alice->>Alice: Encrypt(message, Bob_PublicKey) -> Ciphertext
    Alice->>Bob: Send Ciphertext
    Bob->>Bob: Decrypt(Ciphertext, Bob_PrivateKey) -> message

Unlike symmetric encryption, asymmetric encryption does not require sharing a single key: if a public key is compromised, a new one can simply be reissued using the still-secret private key. However, if the private key is ever compromised, an attacker can decrypt all data ever encrypted with the corresponding public key — so protecting the private key is paramount.

RSA, first described in 1977 by Rivest, Shamir, and Adleman (whose names give the algorithm its name), is one of the most widely used asymmetric algorithms. It supports several key lengths:

Longer keys increase security but degrade performance due to the added computational cost of cryptographic operations. RSA is FIPS 140-2 approved.

Public Key Infrastructure (PKI) builds on asymmetric cryptography using X.509 digital certificates, which bind a public key to an entity’s identity. Anyone wishing to communicate securely with that identity uses its public key to encrypt data. An X.509 certificate contains:

• The subject (identity) the certificate is issued to.
• The trusted CA that issued it.
• The public key and digital signature.
• A validity period.

flowchart TD
    RootCA[Root Certificate Authority] -->|Isolated/locked; highest trust| SubCA[Subordinate Certificate Authority]
    SubCA -->|Issues certificates| RA[Registration Authority]
    RA -->|Verifies applicant identity, accepts requests| Cert[X.509 Certificate Issued]
    Cert --> Entity[End-Entity / Identity]

Because a compromised root CA undermines the trust of the entire PKI hierarchy, it is security best practice to isolate and lock away the root CA rather than using it to issue certificates directly. Instead, a subordinate CA issues certificates on the root’s behalf, working with a Registration Authority (RA) that mediates requests and verifies applicant identity before issuance.

When a certificate must be revoked, the Online Certificate Status Protocol (OCSP) is favored over Certificate Revocation Lists (CRLs), because OCSP checks the status of a single certificate in real time. CRLs are only published at intervals and must be downloaded before use, increasing the window during which a revoked certificate could still appear valid.

Common use cases for asymmetric cryptography / PKI:

• SSH public key authentication — a key pair is generated; the private key stays on the client, and the public key is copied to the server, which later challenges the client to prove possession of the private key.
• Wi-Fi authentication — PKI certificate-based authentication combined with AAA servers (e.g., RADIUS) secures Wi-Fi access.
• VPN connections — secured via Internet Key Exchange (IKE), which leverages the Diffie-Hellman key exchange.
• HTTPS web traffic — secured via TLS certificates.

The Diffie-Hellman key exchange allows two parties to derive a shared secret without ever transmitting it:

flowchart LR
    Tom[Tom: Private Key blue] -->|Compute with public base key yellow| TomPub[Tom Public Key green]
    Mary[Mary: Private Key red] -->|Compute with public base key yellow| MaryPub[Mary Public Key orange]
    TomPub -->|Exchanged| Mary
    MaryPub -->|Exchanged| Tom
    Tom -->|Compute with received MaryPub + own private key| Shared[Shared Secret brown]
    Mary -->|Compute with received TomPub + own private key| Shared

Tom and Mary each hold a private key, and agree on a common public base key. Each cryptographically combines their private key with the base key to produce their own public key. After exchanging public keys, each party combines the other’s public key with their own private key, arriving at the same shared secret — which is then used for secure symmetric communication.

Finally, the TLS 1.3 handshake used to secure HTTPS:

sequenceDiagram
    participant C as Client
    participant S as Server

    C->>S: ClientHello (supported cipher suites, key shares, client random)
    S->>C: ServerHello (selected cipher suite, key share, server random)
    S->>C: Server Certificate
    Note over C,S: Both compute session keys from exchanged key shares + random data
    S->>C: Finished (encrypted with session key)
    C->>S: Finished (encrypted with session key)
    Note over C,S: HTTPS communication now proceeds using session keys

1. Client Hello — includes supported cipher suites, supported key shares, and client-random data used for session key derivation.
2. Server Hello — includes the selected cipher suite, key share, and server-random data.
3. The server sends its certificate for authentication.
4. Both sides compute session keys from the exchanged key shares and random data.
5. The server sends a Finished message encrypted with the session key; the client responds with its own Finished message, also encrypted with the session key.
6. The handshake completes, and the client can now communicate with the server over HTTPS.

Data Integrity, Hashing, and Digital Signatures

Integrity — the “I” in the CIA triad — is supported through hashing, which verifies whether data has been modified. A useful analogy: Bob mails Roger a package and weighs it, affixing the weight to the package alongside the postage. When Roger receives it, he can weigh it again — a mismatch reveals tampering.

Hashing produces a unique digest from input data, functioning as a one-way function: just as a smoothie cannot be “un-blended” back into its original fruit, a digest cannot be reversed back into the original data. If even a single byte of the underlying data changes, the resulting digest is completely different and unrelated to the original.

flowchart LR
    Data[Original Data] -->|Hash function - one-way| Digest[Unique Digest]
    ModifiedData[Modified/Tampered Data] -->|Hash function| DifferentDigest[Completely Different Digest]
    Digest -.->|Cannot reverse| Data

Digital signatures build on hashing to provide both integrity verification and non-repudiation (the signer cannot deny having signed the data):

sequenceDiagram
    participant Bob
    participant Roger

    Bob->>Bob: Create message digest from plaintext (hash)
    Bob->>Bob: Encrypt digest with Bob's Private Key -> Digital Signature
    Bob->>Roger: Send plaintext message + Digital Signature
    Roger->>Roger: Decrypt signature with Bob's Public Key -> original digest
    Roger->>Roger: Compute digest of received plaintext (same hash algorithm)
    Roger->>Roger: Compare digests
    Note over Roger: Match = authentic, unmodified message from Bob

1. Bob creates a message digest of the plaintext.
2. Bob encrypts that digest with his private key, creating the digital signature.
3. Bob sends the plaintext message plus the digital signature.
4. Roger decrypts the signature using Bob’s public key, revealing the original digest.
5. Roger independently computes a digest of the received plaintext, using the same hashing algorithm.
6. If the two digests match, Roger can be confident he received an authentic, unmodified message from Bob.

Common hashing algorithms:

Building on HMAC, JSON Web Tokens (JWTs) are heavily used for securing REST API communication. A JWT is composed of:

• Header — the signing algorithm (e.g., HMACSHA256) and token type (JWT).
• Payload — the actual claims/data (e.g., a name and issued-at time).
• Signature — a digest computed over the encoded header, encoded payload, and a shared secret (for HMAC-signed tokens) or the issuer’s private key (for RSA-signed tokens).

{
  "header": {
    "alg": "HS256",
    "typ": "JWT"
  },
  "payload": {
    "name": "example-user",
    "iat": 1700000000
  },
  "signature": "HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), shared_secret)"
}

With an HMAC-signed JWT (HS256), the authorization server and client agree on a shared secret used to compute and validate the signature. With an RSA-signed JWT (RS256), the signature is instead the RSA-SHA256 digest of the encoded header, encoded payload, and the issuer’s private key — meaning the authorization server signs tokens using its private key, while clients use the corresponding public key to verify authenticity and integrity without ever needing access to the private key.

Cloud Key and Secrets Management

With the proliferation of cloud computing, security engineers must understand cloud key management services.

AWS Key Management Service (KMS) allows creation, storage, and management of cryptographic keys, offering three key types:

AWS KMS also supports hardware security modules (HSMs) via AWS CloudHSM — dedicated hardware performing cryptographic operations (encryption/decryption) and storing keys, supporting key rotation and assignment. CloudHSM devices are FIPS 140-2 Level 3 and FIPS 140-3 Level 3 validated, often required for sensitive federal information processing.

For secrets management, AWS offers:

• Secrets Manager — a secure, centralized repository for sensitive data such as database credentials and API keys, with support for automatic key/secret rotation.
• Systems Manager Parameter Store — suited for configuration data (preferably non-sensitive), but also supports secrets that don’t require automatic rotation.

Both services integrate with KMS, allowing you to encrypt secrets (for example, via a SecureString parameter type) before they are stored.

Importing your own key material into AWS KMS (required for certain compliance scenarios) follows these steps:

flowchart LR
    A[1. Create KMS key shell - no key material] --> B[2. Download RSA wrapping public key + import token]
    B --> C[3. Encrypt your key material using the wrapping public key]
    C --> D[4. Upload/import encrypted key material into the KMS key shell]

This process ensures that AWS (or any third party) never sees your key material in plaintext during upload, since it is encrypted using the downloaded public wrapping key before being imported.

All KMS activity should be audited via AWS CloudTrail, which records both successful and failed API calls, including the source IP address, time, identity, and operation for every key usage event.

Azure Key Vault bundles the equivalent of AWS KMS, Secrets Manager, Parameter Store, and CloudHSM into a single service — allowing management, creation, rotation, and retirement of cryptographic keys and secrets (such as API keys), as well as management of PKI certificates (AWS instead uses Certificate Manager for certificate creation/management).

Module 4: Data Security

Data Exfiltration and Data Loss Prevention

The MITRE ATT&CK framework details the anatomy of a cybersecurity attack, from initial contact through the phase where a threat actor operates inside the environment while evading detection, ultimately capturing and exfiltrating sensitive data. Data Loss Prevention (DLP) is the security control category designed to detect and mitigate this risk.

flowchart TD
    Classify[1. Classify sensitive data - PII, secrets] --> Monitor[2. Monitor for exfiltration]
    Monitor --> Endpoint[Workstation agent]
    Monitor --> Email[Email solution monitoring]
    Monitor --> Network[Network integration - NGFW, SIEM]
    Monitor --> Cloud[Cloud scanning - Purview, Macie]
    Cloud --> Policy[3. Policy enforcement]
    Policy --> Predefined[Predefined vendor policies - PCI DSS, HIPAA]
    Policy --> Custom[Custom policies - data/group/user specific]

Key DLP concepts:

• Classification — scanning the environment for sensitive files containing PII or organizational secrets, and labeling/classifying them.
• Monitoring — detecting exfiltration attempts via a workstation agent, email monitoring, or network integration (passing sensitive data through next-generation firewalls, correlated with SIEM logs).
• Cloud scanning — services such as Microsoft Purview Information Protection scan Azure environments for sensitive data and apply DLP controls; Amazon Macie scans S3 buckets to identify files containing PII.
• Policy enforcement — defining the sensitive data to protect and the action to take if it is detected leaving the environment, via either predefined vendor policies (aligned to standards like PCI DSS, HIPAA) or custom policies.

A representative DLP workflow for a SaaS application, using an on-premises DLP management platform, a cloud DLP proxy, and a Cloud Access Security Broker (CASB):

sequenceDiagram
    participant OnPrem as On-Premises DLP Management Platform
    participant Proxy as Cloud DLP Proxy
    participant CASB
    participant User
    participant SaaS as SaaS Application

    OnPrem->>Proxy: Push DLP policy update
    User->>SaaS: Interact with sensitive data
    SaaS->>CASB: Interaction observed/intercepted
    CASB->>Proxy: Consult DLP policy
    Proxy-->>CASB: Policy decision (allow/restrict)
    CASB-->>User: Block or allow interaction
    CASB->>Proxy: Log action taken
    Proxy->>OnPrem: Forward logs for SIEM integration / investigation

Data Storage Security

Data storage security starts with the data lifecycle: data is created, stored, and secured for use; once compliance-mandated retention periods for archived data expire, the data must be securely removed.

flowchart LR
    Create[Creation] --> Store[Storage/Use]
    Store --> Archive[Archival - retention period per compliance]
    Archive --> Remove[Secure Removal/Destruction]

Four data roles appear consistently across privacy and security policy:

Scenario — an unattended, stolen laptop: an employee working remotely from a public coffee shop steps away, leaving their laptop unattended; a thief steals it. The primary defense here is drive encryption:

• Windows: enable BitLocker, providing AES-256-bit encryption.
• Linux: use Linux Unified Key Setup (LUKS), which relies on dm-crypt to encrypt the drive in a manner similar to BitLocker.

With drive encryption enabled, the thief cannot read the data on the stolen hard drive.

File server security builds on workstation drive encryption with additional controls:

• Firewall ACLs to permit/deny device access to the file server.
• Adequate logging for visibility into which identities, devices, and times accessed file server data.
• Access control lists to govern which identities can access file data.
• Encryption of file data at rest on the server/share.
• Encryption in transit for the protocols used to access the file server:
  • SMB (Windows file shares).
  • SFTP (FTP secured with SSH).
  • FTPS (FTP secured with TLS).

For enterprise-scale storage, a Storage Area Network (SAN) provides high-speed, block-level, consolidated back-end storage. Key SAN security controls:

flowchart TD
    SAN[SAN Fabric] --> Zoning[Zoning]
    Zoning --> Soft[Soft Zoning - by WWN]
    Zoning --> Hard[Hard Zoning - by physical port, more restrictive]
    SAN --> LUN[LUN Masking]
    LUN --> LUNDesc[Restricts hosts to specific Logical Unit Numbers]
    SAN --> Binding[Fabric Binding]
    Binding --> BindDesc[Defines which SAN switches may participate in the fabric]

Backups protect against accidental deletion, disaster (e.g., a hurricane affecting the data center), or ransomware. Options include:

• Off-site storage via a third-party vendor, physically transported from the primary location — introducing risk during transport, even with secure handling.
• Cloud backups, increasingly common with cloud storage adoption. Since the organization lacks physical access to cloud infrastructure, data lifecycle management policies become essential — governing storage tier, expiration, and deletion/removal actions. Cloud providers also offer automated backup services (e.g., AWS Backup).

For single-file/object storage, Amazon S3 Object Lock provides write-once-read-many (WORM) immutability, preventing deletion or modification once written:

Database Security and Compliance

Databases store the bulk of the data used by web applications and organizational systems, and this data is classified as data at rest. Two particularly sensitive data categories require special handling:

• PII (Personally Identifiable Information) — any information that uniquely identifies a data subject.
• PHI (Protected Health Information) — health-related information about a data subject.

Both are typically tied to an organization’s customers or clients, requiring extra diligence to prevent breaches and exfiltration.

Relevant governance, risk, and compliance frameworks:

Relational vs. NoSQL databases:

Database security controls:

flowchart TD
    IAM[Identity & Access Management] --> Local[Local database user]
    IAM --> OS[OS authentication]
    IAM --> Directory[Directory authentication - preferred: SSO, Kerberos]
    IAM --> CloudIAM[Cloud provider IAM - e.g., Oracle Cloud Infrastructure IAM]

    Enc[Database Encryption] --> TDE[Transparent Data Encryption - data at rest, automatic]
    Enc --> ODBC[ODBC + TLS - data in transit]
    Enc --> NoSQLEnc[Database-engine-native encryption - e.g., MongoDB Encrypted Storage Engine]

• Identity and access management for databases can be configured at the database level (local database user), via OS authentication, or — most preferably — via directory authentication, enabling SSO or Kerberos. Cloud database providers (e.g., Oracle Cloud Infrastructure IAM) extend this model to cloud-hosted databases.
• Transparent Data Encryption (TDE) encrypts/decrypts data stored within database tables and namespaces automatically and seamlessly as it is read from and written to storage media.
• Open Database Connectivity (ODBC), when paired with TLS, protects the confidentiality of data in transit to/from the database — distinct from TDE, which protects data at rest.
• For NoSQL databases, it is strongly advised to leverage the database engine’s native encryption (e.g., MongoDB’s Encrypted Storage Engine, which transparently encrypts data before it is written to disk). Each NoSQL engine also provides its own connection drivers per programming language (e.g., MongoDB’s Java driver and Node.js driver); any RESTful API access to a NoSQL database should be secured with HTTPS.
• Compliance requirements should drive routine security testing and penetration testing on at least a semi-annual or annual basis.
• For cloud databases, since the organization lacks physical access to underlying infrastructure, IAM policies combined with encryption are essential. Cloud providers such as AWS and Microsoft Azure also offer database migration services, with a representative assigned to facilitate the move.

SQL injection and the three-tier architecture: a threat actor interacts with a web application at the presentation tier, injecting malicious SQL that is then stored in or extracted from the data tier via the application tier.

flowchart LR
    Client[Presentation Tier - Client/Browser] -->|Malicious SQL injected| App[Application Tier]
    App -->|Processes request| DB[(Data Tier - Database)]
    DB -->|Data extracted/modified| App

Security responsibilities by tier:

Demo: Enabling Transparent Data Encryption on Azure SQL Database

This walkthrough demonstrates enabling Transparent Data Encryption (TDE) and Dynamic Data Masking on an Azure SQL database — a common task for security engineers operating hybrid environments with cloud databases.

1. In the Azure portal search bar, type SQL and select SQL databases.
2. Select Create database. Choose a resource group, then name the database (e.g., testsql).
3. Under server selection, click Create new to open the Create SQL Database Server screen.
   • Provide a unique server name (e.g., testsql with random numbers appended).
   • Select a location (e.g., Central US).
   • Leave authentication set to Use Microsoft Entra-only authentication, and set the Microsoft Entra admin to your own account.
4. Click Select, then OK, leave remaining settings at their defaults, and click Review + Create.
5. Review the deployment summary and click Create, then wait for deployment to finish.
6. Click Go to resource to open the SQL database overview page.
7. In the left navigation, expand Security, then select Data Encryption.
8. Toggle Data Encryption on to enable Transparent Data Encryption, then click Save. Azure begins enabling TDE on the database.
9. Still under Security, select Dynamic Data Masking.
10. Click Add mask to define a masking rule, selecting the target table/column and the masking type. Supported data types for masking include:
    • Personally identifiable information such as birth dates.
    • Payment card information.
    • Email addresses.
    • Numbers.
    • Custom strings.

Combining Transparent Data Encryption with Dynamic Data Masking on an Azure SQL database provides both at-rest encryption and column-level obfuscation of sensitive fields for non-privileged querying scenarios.

Summary

This course examined the two intertwined engineering disciplines of access control and data protection.

Identity and access principles covered:

• The distinction between identification, authentication, and authorization, and how Kerberos implements this using tickets issued by a Key Distribution Center.
• Multi-factor and passwordless authentication, from OTPs to FIDO2 and passkeys.
• OAuth 2.0 for authorization and OpenID Connect for authentication, and how they combine in a token-based workflow.
• Federated identity and SSO, using SAML or OpenID Connect to bridge identity providers and service providers.
• Common identity attacks (brute force, spoofing/impersonation, broken authentication, credential stuffing) and their mitigations.
• Access control models — DAC, MAC, RBAC, ABAC, and dynamic access control — and how RBAC in particular supports least privilege at scale.
• The IAM lifecycle (provisioning, review, revocation), and how it is implemented on-premises via Active Directory/GPOs and in the cloud via services like Entra ID and AWS IAM, plus the distinction between PAM (managing access to resources) and PIM (managing privileged identities).

Data protection principles covered:

• Symmetric vs. asymmetric encryption, their respective performance and key-management trade-offs, and real-world use cases (BitLocker/FileVault, TLS, VPNs, SSH, Wi-Fi).
• Public Key Infrastructure, certificate hierarchies, and revocation via OCSP.
• Hashing, HMAC, digital signatures, and JWTs for verifying integrity, authenticity, and non-repudiation.
• Cloud key and secrets management through AWS KMS/CloudHSM/Secrets Manager and Azure Key Vault.
• Data Loss Prevention (DLP), classification, and CASB-mediated policy enforcement for stopping exfiltration.
• The data lifecycle, data roles (owner, custodian, processor, subject), drive/file-server/SAN storage security, and backup/immutability strategies (S3 Object Lock).
• Database security across compliance frameworks (PCI DSS, NIST SP 800-53, NIST Privacy Framework, NIST CSF, HIPAA, GDPR), encryption approaches (TDE, ODBC+TLS, engine-native NoSQL encryption), and defense against SQL injection across the three-tier architecture.

Quick-Reference Table

Security Engineering Checklist

• Enforce MFA (ideally passwordless/FIDO2) for all privileged and remote-access accounts.
• Use OAuth 2.0 strictly for authorization and OpenID Connect for authentication — never blend the two.
• Apply RBAC as the default access control model; reserve DAC for narrow, low-risk scenarios.
• Review and recertify access on a defined cadence; revoke access immediately upon offboarding.
• Scope GPOs/Conditional Access policies at the domain/OU level, never the forest root.
• Separate PAM (resource-facing controls) from PIM (identity-facing controls) in your access strategy.
• Use symmetric encryption (AES) for speed at rest/in transit; use asymmetric encryption (RSA/PKI) for key exchange and identity binding.
• Isolate and lock the root CA; issue certificates only via subordinate CAs and RAs.
• Prefer OCSP over CRLs for real-time certificate revocation checks.
• Sign JWTs with strong algorithms (HS256/RS256) and validate signatures on every request.
• Centralize key and secrets management (KMS/Key Vault); enable audit logging (CloudTrail/Activity Log) on all key operations.
• Classify sensitive data first, then deploy DLP monitoring across endpoints, email, network, and cloud (Purview/Macie).
• Encrypt data at rest (drive, file server, database via TDE) and in transit (SMB, SFTP/FTPS, TLS/ODBC).
• Apply SAN zoning, LUN masking, and fabric binding for enterprise storage segmentation.
• Use S3 Object Lock (compliance/governance/legal hold) for immutable backup protection against ransomware.
• Map data handling to applicable compliance frameworks (PCI DSS, HIPAA, GDPR, NIST SP 800-53/CSF) and test controls regularly.
• Defend all three application tiers against SQL injection: sanitize/validate at presentation, deploy a WAF at application, and enforce identity-based access at the data tier.

Search Terms

security · engineering · access · control · data · protection · cybersecurity · fundamentals · networking · systems · encryption · identity · 2.0 · authentication · database · management · managing · oauth