Nilesh Kumar

Amazon SageMaker Jupyter notebooks are used to perform advanced data exploration, create training jobs, deploy models to Amazon SageMaker hosting, and test or validate your models. The notebook instance has a variety of networking configurations available to it. In this blog post we’ll outline the different options and discuss a common scenario for customers. Using the Amazon SageMaker console, these are the three options: No customer VPC is attached. Customer VPC is attached with direct internet access. Customer VPC is attached without direct internet access. Each of the three options automatically configures the network interfaces on the managed EC2 instance with a set of routing configurations.  More information here: https://aws.amazon.com/blogs/machine-learning/understanding-amazon-sagemaker-notebook-instance-networking-configurations-and-advanced-routing-options/

AWS IAM (Identity and Access Management) in one of the most complex and misunderstood concepts. It's easy to make mistakes while defining proper permissions for resources in the account or cross account. Here are a few basic terminologies from IAM: IAM users: Used for Human users, such as long term security credentials IAM roles: Used for applications, automated services, they are short term security credentials. For example, a Lambda function wants to access EC2 instance. IAM principal: An identity defines within an AWS account Policies: Policies are permissions- they can be attached to Users, Groups or Roles. AWS authorizes every API call against the IAM policies that apply. Breaking down IAM Policy (JSON files): 'Effect' clause: Describes if an action is allowed or not by setting 'Allow' or 'Deny' 'Action' clause: What all actions on a particular resource can be performed. A wild card (*) indicates all actions, which is very insecur...

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