Cloud
Video: Secure an S3 Bucket
Last week I presented ‘Secure an S3 Bucket (and still use it)’ at the Phoenix DevOps meetup. I’m trying to help people understand why and how to protect every S3 bucket with data that needs to remain confidential. We hosted the meetup using Zoom. Attendee participation was strong and people said the content was on-target,
Why protecting data in S3 is hard and a least-privilege bucket policy to help
Securing data in S3 is a nightmare for many people. This post describes why it’s hard and a least-privilege bucket policy to help.
Guide to Tagging Cloud Deployments
Resource tagging is the primary context communication method in the Cloud but many organizations struggle to define the terms and a model to describe and analyze their Cloud deployments. The k9 Security guide to tagging cloud deployments will help you define your tagging standard and explain why it’s important.
Assessing and Managing Information Security Risks
Reading Time: 6 minutes The current crop of Best Practice tagging schemes and recommendations don’t describe the context required for people or tools to assess security or manage risk easily. But I never explained why risk management is important nor how to assess risk. Let’s start with an introduction to the process of managing risk
Research: Problems Engineers have Securing Cloud Deployments and ‘Shift Left’
I hit an obstacle on my way to extending the common resource tagging models with context to describe security and risk attributes. I couldn’t get past that while I feel this should be a settled engineering practice, it isn’t. Suspecting bad assumptions lurking around, I spoke to some engineers practicing DevOps with titles like DevOps
The context people and tools need to work with your Cloud
Operating applications involving more than a few components without explicitly modeled contextual clues is difficult for humans and might be impossible for tools. This is especially true when people are a couple steps removed such as is often the case when analyzing costs and/or assessing risk. Both people and tools rely on: identifying resources at
Cloud native application-level identity and access control
The proper way to provide identities to applications on Cloud and container platforms is for the compute platform to provide that identity to the application instance . I call this the Cloud native application identity. Once the application has received its identity from the compute platform along with an identity document or credential the application
Better Network-based Identity and Access Control in the Cloud
This is the second post in a series about how the Cloud is changing how we manage network access control and application identity. In particular, my thesis is that the use of a network-centric identity such as an IP address or subnet to identify an application is waning and are being replaced by identities provided
Zed, authorizing application access via network controls is (nearly) dead
One challenge many organizations face when migrating their applications to Cloud or container platforms is that identifying applications by their network address, either CIDR block (aka subnet) or IP address no longer “works.” Identifying application instances by their network address no longer works the way it used to because the compute instances are much more
Cloud Pattern: Secure Inbox using S3 and KMS
With the Secure Inbox pattern, organization A can store and deliver objects of arbitrary size to partners while narrowly scoping what partner data its own teams and applications have access to. Organization B can receive work generated by partners reliably and securely while maintaining tight control over who has access to that data via KMS encryption key and bucket policy.
Preventing 3rd-Parties from Leaking Data in Cloud – Attunity
Let’s examine three controls customers can adopt to help keep control of their data stored in S3 or another Cloud object store while still making it accessible or manageable by third parties.
Provable Security at AWS
Helping customers answer security questions in the general case and preventing bad configurations from making it into the wild is one of the main themes at AWS’ inaugural Security conference, re:Inforce. They have done this by operationalizing the ‘Provable Security’ field for their services.
Concepts: Zones and Regions
The major cloud providers provide a Region+Zone model to help you architect, deploy, and operate applications built upon isolated fault domains with well-defined behaviors. Learn the characteristics of your Cloud provider’s model and architect a deployment that will meet your availability goals prior to deploying your application.
Concept: Failure Domain
A failure domain is a set of resources that provide a service to users and operates independently of other failure domains that provide that same logical service. And they are incredibly important.
Consuming Secrets in Applications
Explore the three main methods, advantages, and disadvantages for applications to consume (use) secrets stored in a vault: environment variable, file, and API.
Identifying Undifferentiated, Heavy Lifting
In The Promise of Clouds and Optionality, I said: Cloud providers are competing to offer high quality services that meet their customers’ needs at decreasing cost and increasing scale. They want you to offload whatever you consider undifferentiated heavy lifting to them. But what the heck is ‘undifferentiated, heavy lifting’ and where do I find
The Promise of Clouds and Optionality
The real magic Cloud providers give you is optionality to build the right thing.
Starting Carefully with Service Control Policy
Let’s say you’re excited about using Service Control Policy to govern what goes on in your organization’s AWS accounts and improve compliance, but you don’t want to break the world when you roll it out. How do you do that? Start by identifying a single account that serves an active, but low risk use case
Improving Enterprise Security and Compliance with AWS Organizations
Let’s examine how AWS Organizations helps you manage and improve some aspects of Enterprise-wide security and compliance. This discussion builds on the previous post detailing how AWS Organizations help you manage many AWS accounts and their costs. AWS Organizations provide a number of additional security features, the one we’ll examine today is Service Control Policy.
Managing Multiple AWS Accounts and Costs with an AWS Organization
Previously, we explored the benefits of the security and fault boundaries provided by AWS accounts, and provisioning accounts to match your use cases in order to operate safely in the Cloud. Today, we’ll explore the AWS Organization service and why you should use it to manage your enterprise’s AWS accounts. When you deploy distinct use
How should I organize my AWS accounts?
Previously, I answered ‘How many AWS accounts do I need?’ with: Create however many accounts your organization needs to establish safe security and fault boundaries that enable your organization’s primary use cases and expected level of team/application autonomy. Today, we’ll explore the tradeoffs of AWS account organization methods using an example that covers one approach
How many AWS accounts do I need?
Today, I’d like to answer a common question people ask about AWS accounts: How many AWS accounts do we need? What’s an AWS Account? First let’s start with some background about what an AWS Account is and the features it provides. An AWS Account is a logical container that owns resources in the AWS Cloud.