Nilesh Kumar

Nice documentation on how to secure AWS SageMaker: https://docs.aws.amazon.com/sagemaker/latest/dg/security.html

AWS Landing zone: A framework for defining and creating foundations for accounts by automating, baking security baseline, controls, governance, organized, auditable, scalable and self serviceable. A set of best practices ingested in an AWS account before migration. Reliable infrastructure. The tenet of LZ are: - Automation driven versioned infrastructure, such as CI/ CD, Cloudformation templates - Multi-account AWS environment based on AWS best practices, limiting blast radius - Adaptable foundation with guardrails, safeguarding in case of any mis happening - Set of architecture patterns, proxy accesses Building/ Designing LZ components: - Accounts: as discussed Multi account strategy - Network:Domains, Direct Connect, Core Services - Security: Centralized Logging, Configuration, Image (AMI) - IAM: Access, Identity, Federation - Cloud Users: Provide users to deploy the accounts, services by using Service Catalog, Automation (avoid manual steps) etc - Now, Migrate, Iterat...

The below are a few security anti patterns for AWS cloud which should be avoided when implementing comprehensive cloud security strategy: Security Anti-patterns Categories: - Account Structure - N/w design - Auditing - S/W delivery AntiPattern (Account Structure): Personally owned AWS account - Make sure the Root account (login, MFA) is not tied to a person's email id. Root email id should be tied to team DL - Root MFA must be tied with some sort of official hardware device - Contact info etc must be of office address - No one logs into the account root. Use IAM only. Anti-pattern (Account Structure): AWS account overcrowding - Not all and every services/ teams should be placed under one single account. It becomes very hard to manage policy wise and governance wise - If admin creds for the account is compromise, the blast radius will be more, all the services get compromised - If some of the services are in scope for compliance, and since they are not separated, i...

Interesting read on how overlooked, underestimated accounts with over privileges can be misused. This is not new and have been found in traditional corporate environments but now this applies to Cloud environments also. The blog sums it up nicely: https://www.cyberark.com/threat-research-blog/cloud-shadow-admin-threat-10-permissions-protect/

One of the most popular, yet most misunderstood and misconfigured services of AWS, common to be explouited frequently out in wild. Latest on this, a good read: https://www.upguard.com/breaches/facebook-user-data-leak

A Policy is 'Deny' by default Types of Policies: 1. SCP- SCP or Service control polcies. AWS Organizations use this kind of policies.For example, Guardrails to disable service access on the principals in the account. 2. IAM- Permission Policies and Permission Boundaries- Granular permissions on IAM principles (users and roles) and control maximum permissions they can set. 3. AWS STS- Security Token Service- Reduce general shared permissions further 4. Resource based policies: Cross-account access and to control from the resource 5. Endpoint polices- generally attached with VPCs- Control access to the service with a VPC endpoint. How all these policies work together- within an account: SCP AND [IAM policies OR Resource based policies]- If both policies match- then the matched action will be allowed, otherwise denied. How all these policies work together- across accounts: SCP AND [IAM policies AND Resource based policies]- All the 3 must have the same actions matched- the action...

Introduction: Metadata server: Every EC2 instance has some user scripts which can be used to pull configuration to launch that EC2 instance. Those configs are stored on a Metadata server (169.254.169.254) 'private' to that Ec2 instance. Each time an Ec2 instance starts , AWS attached the " meta data server" to it, which can be accessed from the instance itself using http://169.254.168.254. The instance meta-data stores information such as :AMIid, Private IP address, Instance Type etc...and... User-data: OS boot scripts: AWS allows you to boot up the EC2 using a custom User-data scripts- such as web application, Apache web server, keys. credentials etc. This script, also called user data, is stored by AWS in the instance metadata and retrieved by the OS during boot. Instance profile: When EC2 instance wants to access other services such as S3, it uses credentials to access it. Instance profiles give Ec2 instances a way to access AWS services. AWS creates a unique se...