Cloud Detection & Logging Architecture

Identity Security · IAM · Zero Trust · Okta · Cloud Access

Building a More Scalable Identity and Access Model

Identity is one of the most important security boundaries in a modern environment.

As organizations grow, access often becomes harder to manage. Users accumulate permissions over time, applications are integrated differently, privileged roles remain assigned longer than necessary, and access decisions become increasingly difficult to review.

I worked on improving identity and access management by moving toward a more centralized, group-driven, and least-privilege model across cloud and SaaS environments.

The goal was to make access:

Consistent

Auditable

Scalable

Least-privileged

Easier to manage over time

The Problem

Identity environments often become fragmented because access is added incrementally.

A user needs access to an application.

An administrator grants it directly.

A developer needs elevated cloud permissions.

A role is assigned manually.

A team expands.

Another set of exceptions is created.

Over time, this creates several common problems:

• Direct user assignments

• Inconsistent role definitions

• Persistent privileged access

• Difficult offboarding

• Hard-to-audit permissions

• Application-specific access models

• Manual provisioning

• Role drift

• Excessive access after job changes

The challenge is not simply authenticating users.

It is understanding:

Who should have access to what, why, and for how long?

My Approach

I focused on making identity more centralized and policy-driven.

The broader model was based around:

Centralized Authentication

↓

Group-Based Authorization

↓

Role-Based Access

↓

Least Privilege

↓

Continuous Review

This helped move access decisions away from one-off user assignments toward reusable access patterns.

Okta as the Identity Layer

Okta was used as a central identity provider for multiple applications and services.

This included work around:

• Single Sign-On

• SAML integrations

• OIDC/OAuth integrations

• SCIM provisioning

• Group-based application assignment

• MFA

• Lifecycle management

• Access reviews

Centralizing authentication reduced the need for separate credentials across multiple applications.

It also improved visibility into who had access and how authentication was being enforced.

SAML, OIDC, and SCIM

Different applications support different identity standards.

Understanding those differences is important when designing access.

SAML

SAML was commonly used for enterprise SSO.

It allowed authentication to be delegated to the identity provider rather than maintaining separate application passwords.

OIDC / OAuth

OIDC and OAuth provided a more modern authentication and authorization model for applications and APIs.

These integrations often required careful review of:

• Redirect URIs

• Scopes

• Client permissions

• Token lifetime

• Application trust

SCIM

SCIM helped automate user lifecycle management.

Rather than manually creating and removing accounts inside every SaaS platform, provisioning could be tied more closely to the central identity system.

This reduces orphaned accounts and improves offboarding.

Group-Based Access

One of the most important improvements was moving away from direct individual assignments.

Instead, access could be tied to groups.

For example:

User

↓

Identity Group

↓

Application Role

↓

Authorized Resource

This makes permissions easier to understand and manage.

Instead of asking:

Why does this person have access?

you can ask:

What group gives them access, and why are they in that group?

That is a much more scalable question.

Structured Group Naming

A structured naming model can make identity significantly easier to operate.

For example, group names can encode:

• Scope

• Environment

• Application

• Role

A structured pattern makes permissions easier to recognize during:

• Access reviews

• Troubleshooting

• Audits

• Provisioning

• Offboarding

The exact naming convention matters less than consistency.

AWS Identity Center

Cloud access was also an important part of the identity model.

AWS Identity Center can provide centralized access to AWS accounts and roles.

Instead of relying on long-lived IAM users or individually managed credentials, users can access AWS through centrally managed identities and role assignments.

This supports:

• SSO

• Centralized access management

• Role-based permissions

• Short-lived credentials

• Easier offboarding

• Reduced credential sprawl

Least Privilege

Least privilege sounds simple:

Give users only the access they need.

In practice, it is much harder.

Access needs change.

Teams move.

Projects end.

Temporary privileges become permanent.

The goal should therefore be:

Minimum necessary access, reviewed continuously.

Least privilege was considered across:

• AWS

• SaaS applications

• Administrative roles

• Development tooling

• Security platforms

• Endpoint administration

Persistent Privilege

One of the highest-risk identity patterns is persistent administrative access.

If someone only needs elevated access occasionally, permanent admin rights increase risk without providing proportional value.

Better patterns include:

• Temporary elevation

• Separate privileged roles

• Just-in-time access

• Approval workflows

• Break-glass accounts

• Strong MFA

• Session logging

Even when a full PAM platform is not available, the principle remains useful:

Elevated access should be exceptional, not normal.

Zero Trust

The identity design also aligned with Zero Trust principles.

Zero Trust does not mean “trust nobody.”

It means access should not be granted solely because someone is:

• On the corporate network

• Using a company laptop

• Inside the cloud environment

• Already authenticated

Instead, access decisions should consider:

• Identity

• Authentication strength

• Device posture

• Role

• Resource sensitivity

• Context

• Ongoing authorization

Defense in Depth

Identity controls are stronger when combined with other protections.

For example:

SSO

MFA

Managed endpoint

Least privilege

Logging

Access review

is stronger than any single control by itself.

This is why identity security should not be treated as a standalone system.

It intersects with endpoint security, cloud security, logging, and incident response.

Joiner, Mover, Leaver Lifecycle

Identity security is heavily influenced by employee lifecycle events.

Joiners

New employees should receive standardized access based on role rather than ad hoc assignments.

Movers

Role changes are particularly dangerous because users may retain old access while gaining new permissions.

Leavers

Offboarding should remove access quickly and consistently.

SCIM and centralized identity help reduce manual steps during these events.

Human and Non-Human Identities

Identity is no longer only about employees.

Modern environments also contain:

• Service accounts

• API keys

• CI/CD identities

• Cloud roles

• Kubernetes service accounts

• Machine identities

• AI agents

These identities can be just as privileged as human users.

In some cases, they are more privileged.

That means identity programs increasingly need to consider:

Humans

and

Machines

using the same principles:

• Least privilege

• Clear ownership

• Short-lived credentials

• Rotation

• Logging

• Review

Practical Tips & Tricks

1. Prefer groups over direct assignments

Direct assignments are harder to review and easier to forget.

Use:

User → Group → Role

whenever practical.

2. Make group names understandable

A group called:

admins-2

does not tell you much.

A structured name can indicate:

• Application

• Environment

• Role

• Scope

That makes reviews much easier.

3. Avoid long-lived cloud credentials

Where possible, use:

• SSO

• Role assumption

• Temporary sessions

• Workload identity

Long-lived access keys increase both operational burden and security risk.

4. Separate privileged access

Administrative access should be clearly distinguishable from normal user access.

This improves:

• Logging

• Review

• Incident investigation

• Risk awareness

5. Review movers carefully

Employees who change teams often accumulate permissions.

A role change should trigger:

Add new access

and

Remove old access

not just the first half.

6. SCIM reduces offboarding risk

Automated deprovisioning is one of the most valuable benefits of SCIM.

It reduces reliance on someone remembering to manually disable every SaaS account.

7. Authentication is not authorization

A user successfully logging in does not mean they should have access to every resource.

Keep these concepts separate:

Authentication: Who are you?

Authorization: What are you allowed to do?

8. Track service accounts like employees

Every non-human identity should have:

• An owner

• A purpose

• Defined permissions

• Credential lifecycle

• Logging

If nobody owns a service account, it is already a risk.

9. Reduce shared accounts

Shared credentials make attribution difficult.

Whenever possible, actions should map back to a specific identity.

10. Design access with offboarding in mind

A good identity model should answer:

If this person left today, could we confidently remove their access?

If the answer is unclear, the model probably needs improvement.

Access Review Strategy

Periodic access reviews should focus on questions such as:

• Does this user still need the role?

• Is the role broader than necessary?

• Are privileged users still active?

• Are dormant accounts present?

• Are service accounts still needed?

• Are direct assignments bypassing the intended model?

Access reviews are more useful when the underlying identity structure is already clean.

Logging and Investigation

Identity telemetry is also critical during incident response.

Useful sources can include:

• Okta logs

• AWS CloudTrail

• AWS Identity Center events

• SaaS audit logs

• Endpoint telemetry

• Authentication logs

This helps answer questions such as:

• Who authenticated?

• From where?

• What role was assumed?

• What resource was accessed?

• Was MFA used?

• Was access expected?

Outcome

The work helped create a more structured identity model based on centralized authentication, group-based authorization, and least-privilege access.

It improved:

• SSO consistency

• Access visibility

• Role organization

• Provisioning

• Offboarding

• Cloud access management

• Least-privilege enforcement

• Identity auditability

More importantly, it moved identity away from ad hoc access assignment and toward a more scalable security architecture.

Technologies

Okta · SAML 2.0 · OIDC · OAuth 2.0 · SCIM · AWS IAM · AWS Identity Center · RBAC · MFA · SaaS Security · Cloud Identity

What This Demonstrates

This project demonstrates experience in:

• Identity and access management

• Zero Trust

• Least privilege

• Okta

• SSO

• SAML

• OIDC/OAuth

• SCIM

• AWS IAM

• Cloud identity

• RBAC

• SaaS security

• Access governance

Key Takeaway

Identity scales best when access is attached to roles and groups—not individual people—and when privilege is treated as temporary rather than permanent.

Short Case Study Card

Identity & Least-Privilege Modernization

Improved identity architecture across cloud and SaaS environments using Okta SSO, SAML/OIDC, SCIM, AWS Identity Center, group-based authorization, and least-privilege access patterns.

IAM · Okta · Zero Trust · AWS Identity Center · SSO

Next is #5: Cloud Detection & Logging Architecture. That one can get especially technical around GuardDuty publishing, centralized S3/KMS, Macie, WAF logging, CloudTrail, Security Hub, log validation, retention, and some very useful “logging mistakes to avoid” tips.

next

Cloud Detection & Logging Architecture

Detection Engineering · AWS · Logging · Security Operations

Building Reliable Security Telemetry Across a Multi-Account AWS Environment

Security monitoring depends on visibility.

A detection platform can only identify suspicious activity if the underlying telemetry is consistently generated, delivered, retained, and available during an investigation.

In a distributed AWS environment, that becomes more difficult because security data may originate from many different services, accounts, and regions.

I worked on improving the architecture and consistency of security telemetry across a multi-account AWS environment, including both commercial AWS and AWS GovCloud.

The focus was not just on enabling security services, but on ensuring that the resulting logs and findings were actually usable.

The Problem

As cloud environments expand, security logging often becomes fragmented.

Some accounts may have strong visibility while others have gaps.

Common issues include:

• GuardDuty enabled without centralized publishing

• WAF logging disabled

• Macie results stored inconsistently

• CloudTrail visibility differing between accounts

• Encryption misconfigurations

• Logs sent to the wrong destination

• Regional differences

• Missing retention standards

• Security findings generated but not integrated into the broader monitoring workflow

This creates a dangerous problem:

A security control can appear configured while still failing to provide useful evidence during an incident.

The goal was to reduce that gap.

My Approach

I approached the problem as a telemetry pipeline:

Generate

↓

Encrypt

↓

Centralize

↓

Retain

↓

Validate

↓

Investigate

Each part matters.

Generating a log is not useful if it is lost.

Centralizing a log is not useful if it cannot be decrypted.

Retaining a log is not useful if nobody knows where to find it.

And enabling a security service is not enough if it is not actually publishing.

Amazon GuardDuty

GuardDuty was a major part of the cloud threat-detection strategy.

The work included reviewing GuardDuty across accounts and regions and ensuring findings could be exported to centralized destinations.

The validation process went beyond checking whether a detector existed.

Checks included:

• GuardDuty detector present

• Detector enabled

• Publishing destination configured

• Publishing destination active

• Expected S3 destination configured

• Expected KMS key configured

• Publishing status healthy

This helped confirm that GuardDuty was not only running, but also contributing usable telemetry to the security environment.

Centralized GuardDuty Publishing

Centralized publishing was useful for creating a more consistent investigation model.

Instead of treating each AWS account as a separate security island, findings could be routed toward controlled central storage.

That provided benefits such as:

• Easier investigation

• Consistent retention

• Reduced account-by-account searching

• Better forensic availability

• Centralized security ownership

The configuration required coordination between:

GuardDuty

Amazon S3

AWS KMS

IAM

If any one of those pieces was incorrect, publishing could fail.

Amazon Macie

Macie was used to improve visibility into sensitive data.

The work included reviewing discovery-result configuration and ensuring long-term results could be stored in an appropriate centralized repository.

This required attention to:

• S3 bucket configuration

• KMS encryption

• Macie service permissions

• Regional setup

• Publishing configuration

• Security Hub integration

Macie was especially useful because traditional infrastructure monitoring may tell you that a storage resource is exposed but not necessarily what kind of data exists inside it.

Sensitive-data context can materially change prioritization.

AWS Security Hub

Security Hub helped bring together security findings and configuration signals from multiple AWS services.

It provided another layer of visibility into:

• Misconfigurations

• Security standards

• Vulnerabilities

• GuardDuty findings

• Inspector findings

• Macie findings

• Account posture

The important distinction was that Security Hub was treated as one source of evidence rather than the only source.

During investigations, findings were correlated with underlying AWS telemetry and security platforms where appropriate.

AWS CloudTrail

CloudTrail was one of the most important investigative data sources.

It provided visibility into API-level activity across AWS.

During security investigations, CloudTrail can help answer questions such as:

• Who performed an action?

• Which credentials were used?

• Which API was called?

• When did the action occur?

• Which resource was affected?

• Which IP address initiated the request?

• Was a role assumed?

• Were permissions changed?

CloudTrail is particularly valuable when investigating identity-based activity.

AWS WAF Logging

Web application firewalls are much more useful when the events they observe are retained.

I worked on reviewing active AWS WAF Web ACLs and identifying whether logging was enabled and pointed toward the intended destinations.

Important checks included:

• Identify active Web ACLs

• Determine whether logging exists

• Validate destination configuration

• Confirm expected log delivery

• Identify Web ACLs missing logging

• Document remediation

This helped improve visibility into traffic reaching internet-facing services.

WAF Configuration Lessons

WAF rules can introduce unexpected behavior.

For example, managed rule groups may block traffic that should be allowed for known trusted sources.

In those cases, rule ordering matters.

A trusted IP allow rule may need to execute before broader managed protections depending on the intended policy.

The lesson is not to weaken WAF protections.

The lesson is:

Understand how rule priority affects the final authorization decision.

Security controls need to reflect both risk and business requirements.

AWS Config

AWS Config was another valuable source of cloud-security telemetry.

While CloudTrail answers:

What action occurred?

AWS Config can help answer:

What did the resource configuration look like?

This distinction becomes valuable when investigating configuration drift or understanding how a resource changed over time.

Config also supports other security controls that depend on resource inventory and configuration data.

Centralized S3 Storage

Security logs frequently converge on Amazon S3.

That makes the security of the logging bucket itself important.

A centralized logging repository should consider:

• Encryption

• Bucket policies

• Access restrictions

• Secure transport

• Retention

• Versioning

• Cross-account permissions

• Deletion protection

• Lifecycle management

Security logs should not be easy for the same compromised identity to delete.

KMS Encryption

KMS was used to protect sensitive security telemetry.

However, encryption can introduce operational issues if key permissions are incorrect.

The producing AWS service must have sufficient permission to use the key.

The security team must also retain the ability to access the data later.

That means KMS design needs to account for both:

Data protection

and

Operational accessibility

A perfectly encrypted log that nobody can decrypt during an incident is not very useful.

Log Retention

One challenge in security operations is balancing retention with cost.

Keeping every log in expensive hot storage indefinitely is rarely practical.

A more scalable model can separate:

Hot retention

from

Long-term archival

For example, recent logs may remain readily searchable while older logs move to lower-cost archival storage.

This supports both operational investigations and longer-term compliance requirements.

Validation

As with the broader AWS security standardization work, validation was a major focus.

A configuration was not considered successful simply because an API request returned successfully.

Validation could include confirming:

• Destination exists

• Destination is active

• Correct S3 bucket

• Correct KMS key

• Security service publishing status

• Required account coverage

• Required region coverage

• Logs actually arriving

This created greater confidence in the security telemetry pipeline.

Commercial AWS and GovCloud

Logging architecture needed to account for both commercial AWS and AWS GovCloud.

The security objectives remained similar, but implementation details differed.

Considerations included:

• Different partitions

• Different region names

• Separate organizations

• Separate centralized resources

• Service availability

• Independent security boundaries

Automation and validation therefore needed to be aware of which environment they were operating within.

Detection-in-Depth

No single source provides complete visibility.

A stronger detection architecture combines multiple telemetry layers.

For example:

Identity activity
CloudTrail

Threat detection
GuardDuty

Configuration changes
AWS Config

Sensitive data
Macie

Internet traffic
AWS WAF logs

Vulnerability context
Security Hub / Inspector / Wiz

Endpoint or workload activity
EDR / container security

Together, these signals provide much richer investigative context than any single platform.

Practical Tips & Tricks

1. Never treat “enabled” as the final check

Always validate whether the service is doing what you expect.

For GuardDuty, that means checking publishing.

For WAF, it means checking log delivery.

For Macie, it means checking result storage.

2. Know where your logs actually live

During an incident is the wrong time to discover that nobody knows the destination bucket.

Document:

• Account

• Region

• Bucket

• Encryption

• Retention

• Ownership

3. Centralize without creating a single point of failure

Centralized logging is useful, but the destination account needs strong protections.

Consider limiting who can:

• Delete logs

• Modify bucket policies

• Change KMS keys

• Alter retention policies

4. Test KMS permissions early

Many logging failures are actually encryption-policy failures.

When implementing a new destination, validate that the AWS service can use the intended KMS key.

5. Separate telemetry generation from telemetry retention

The service producing the log and the system storing the log are separate concerns.

Design both intentionally.

6. Verify real delivery

If practical, confirm that recent objects are appearing in the destination.

A configured destination does not guarantee successful delivery.

7. Standardize retention

Different teams choosing arbitrary retention periods creates investigation gaps.

Define an organizational retention strategy.

8. Protect your logs from the identities they monitor

If an administrator can compromise a workload and also delete the evidence with the same credentials, detection becomes much weaker.

Logging environments should have separation of duties where practical.

9. Build account and region coverage reports

A simple matrix can quickly reveal telemetry gaps.

For example:

AccountRegionGuardDutyConfigMacieWAF LogsAus-east-1✅✅✅✅Bus-east-1✅✅❌✅Cus-west-2✅❌✅N/A

This makes gaps obvious.

10. Design for investigations, not just compliance

A logging control should answer:

Would this data actually help me reconstruct what happened?

If not, the control may satisfy a checkbox without providing enough security value.

Logging Mistakes to Avoid

Some recurring mistakes can weaken cloud-security visibility.

Mistake 1: Enabling GuardDuty without checking export

The detector exists, but historical findings may not be retained where expected.

Mistake 2: Enabling WAF but not WAF logging

Blocking traffic without retaining the event limits investigative value.

Mistake 3: Assuming CloudTrail contains everything

CloudTrail is powerful, but it does not replace:

• Network telemetry

• Application logs

• Endpoint logs

• Kubernetes audit data

Mistake 4: Forgetting encryption permissions

A logging destination may exist but silently fail because the producing service cannot use the KMS key.

Mistake 5: Inconsistent retention

One account may retain logs for years while another retains them for weeks.

That makes organization-wide investigations inconsistent.

Mistake 6: Centralizing without validating

Centralization is only useful when logs actually arrive.

Operational Monitoring

Once logging is configured, the logging architecture itself should be monitored.

Useful questions include:

• Has log volume unexpectedly dropped?

• Is a publishing destination failing?

• Did a bucket policy change?

• Did a KMS policy change?

• Was logging disabled?

• Was a security detector removed?

Monitoring the monitoring system is an important part of defense in depth.

Outcome

The work improved security visibility across multiple AWS accounts and regions.

It helped create more consistent:

• Threat-detection telemetry

• Audit logging

• Sensitive-data monitoring

• WAF visibility

• Centralized log storage

• Encryption

• Retention

• Cross-account validation

It also improved confidence that security services were not simply configured, but actually delivering usable security data.

Technologies

Amazon GuardDuty · AWS Security Hub · AWS CloudTrail · AWS Config · Amazon Macie · AWS WAF · Amazon S3 · AWS KMS · AWS Organizations · IAM · AWS CLI · Security Logging · Detection Engineering

What This Demonstrates

This project demonstrates experience in:

• Detection engineering

• AWS security monitoring

• Cloud logging architecture

• Threat detection

• Incident-response readiness

• Centralized telemetry

• Security-data retention

• Encryption

• Multi-account AWS security

• GovCloud

• Automation and validation

Key Takeaway

A security control is only as useful as the telemetry it produces—and telemetry is only valuable if you can reliably find, trust, and use it during an investigation.