Cloud Security – An Architect’s Perspective

We as architects often hear the term Cloud’s “Shared Responsibility Model” and with application development background we usually leave it to organization’s Cloud Infra architects/ Cloud Infra teams (CIT) to participate in that model keeping ourselves focused on enterprise applications. Let’s re-visit the popular Shared Service Model:

(ref: https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility)

Just focusing on Cloud deployments (so ignoring on-prem vertical) we realize that Operating System Upgrades, Network Controls (like firewall, VPN Gateways etc) and Devices are generally handled by centralized Cloud Infra teams (CIT) and device teams (if not, then as Enterprise Architects we need to build processes around it), Regardless of the type of deployment, an organization retain the responsibilities around:

Data
Endpoints
Account
Access management

It becomes imperative that as architects we build processes, propagate it to development teams (and enforce it!!!). In this article we will discuss some of the points from the application development perspective that can help strengthen cloud security.

Data:

Irrespective of data being in rest, use or motion state, following processes needs to be built:
a. Data Encryption:
Whether we are using Database (PaaS or deployed on VM) or Object Store ( S3/Blob) for storing data, the data should always be encrypted. This can be easily achieved using the Key Management/Key Vault services available with cloud providers. For data in motion the end-points should always be configured over secure protocols (TLS enabled).

b. Data Access Controls:
Enforce Role Based Access Controls (RBAC) for determining who can access the data-stores (DB or Object Store). Identity and Access Controls (IAM) service plays a vital role in enforcing this. Always start with Principle of Least Privileges.

c. Make Access Visible:
Use right tools for proper visibility on who is accessing the data. Services like App-Insight, CloudWatch or enterprise tools like DataDog can be used to enable such insights.

Endpoints:

I generally classify endpoints into 3 major segments:

a. Physical Devices (like IOT devices/mobiles etc):
The device management team, usually takes care of setting up anti-viruses, endpoint security etc on the device. However with smaller IOT devices where security clients cannot be installed due to low memory/computing power constraints, we cannot rely on just these softwares. At enterprise level, we need to:

Create Risk profile for different device types.
Create different network segments (vnets/subnets) for IOT devices and keep them separate from the critical enterprise systems. For devices with different risk profiles, create different network segments.
If possible, enable the use the Hardware Security Module (HSM) available in the IOT device to store the secure information.
All the communications with the devices (IOT or not) should be using secure channels (MQTTS/ HTTPS).

b. API Endpoints:
The API end-points, needs to be secured by enabling their access over secure protocols only, limit throttled, and access and authorization policies set by services like API Gateways or API Management services.

c. Network Ports:
By default, the Security Group polices for EC2 and Azure VM prevents any inbound connections. However, over time ports get opened as new libraries/frameworks gets added or software gets installed, it is imperative that regular audits of such VMs happen, and exception obtained with business justification on regular basis. Same goes for AKS clusters or containerized system.

Cloud Account Management:

The cloud account management can be achieved either by creating sub-accounts (AWS model) or Management Groups & Subscriptions (Azure model). Both the models offer decent isolation. However, these needs to be planned carefully to be effective, few months back during a customer interaction I suggested following that worked nicely for them:

a. Create/Establish separate subscription for:

Network: Azure Virtual WAN hub, private DNS and other networking resources, this ensures that all base network resources are billed together and are isolated.
Monitor: Global management capabilities like Azure Monitor Log Analytics workspaces and Azure Automation run books.
Identity: Identity services to host Windows Server Active Directory DC or Azure Active Directory (AAD).
Environment: Production, Non-Production, R&D etc

b. Create Delegated Accounts for Administrators
c. Use Managed/Service Identities wherever possible for application access.
d. Set the Password Rotation Policies for User Accounts/Identities.

There are other finer points as well but will end this topic here to keep it succinct.

Identity & Access Management:

Most of the cloud providers have given the best practices around IAM. I found them good enough for my projects:

Apart from above I usually recommend following guidelines to my application architects.

General Guidelines:

Enable Good software development practices like using security patched software/libraries in the application, high test coverage, enable usage of code analyzers like SonarQube, findbugs etc.
Review of OWASP Top 10 and build remedial actions in the software.
Promote Penetration Testing (PEN tests) and application security testing on the software before any release (especially the public ones).
Enable infrastructure that allows for the scanning of docker images for any vulnerabilities. Tools like Docker Scan/Docker Scout can be utilized here.
Enable integration of all applications, infrastructure, services with the centralized monitoring tools like App-Insights, AppDynamics, Datadog etc
Clearly Document all the processes and share it across teams/groups within the organization.
Report, don’t hesitate on any security issue.
Establish that security is everyone's responsibility.