I am trying to find out if it is correct to say that - In AWS we can only perform vulnerability scanning for EC2 instances.
From my research, it seems like there can be pen tests on other AWS services, but vulnerability scanning seems to be focused on EC2? (https://aws.amazon.com/security/penetration-testing/). If so, would it be safe to assume that vulnerabilities scans can be only focused on EC2 instances, but also periodic pen tests on the AWS services listed in the link above?
Any help is appreciated.
You are correct in seeking out pentesting which goes beyond EC2. However, the type of testing (if any) is highly dependent on which specific services you use.
It's very common that pentests do not cover all services only because they are improperly scoped. Not all AWS services will be relevant to a penetration test, but some may be critical. Here are some worthwhile misconfigurations to consider:
S3 - Buckets have their own access controls and unique API. Without insight to bucket names and AWS expertise, a pentester cannot determine if they are misconfigured. It is fairly common for buckets to allow access to AllUsers which is very dangerous.
RDS - You should make sure that databases are not publicly accessible from the internet (for obvious reasons).
Cognito, SNS, SQS - If you are pentesting an application, you will need to take a close look at the permission and configuration of authentication and messaging services (if they are in use). Misconfigurations here can allow someone to self-enroll in applications they shouldn't.
It would be worthwhile to spend some time to evaluate each service and get an understanding of it's attack surface. Here's an AWS pentesting guide for reference.
Related
I’m my scenario wants to separate out the production environment from our development environments.
We'd like to only have our production systems on one AWS account and all other systems and services on another.
I'd like to split/separate for billing purposes. If I do add more monitoring services many charge by the number of running instances. I have considerably more running instances than I need to monitor though so I'd like the separation. This also would make managing permissions in the future a lot easier I believe (e.g. security hub scores wouldn't be affected by LMS instances).
I'd like to split out all public facing assets to a separate AWS account. So RDS, all EC2 instances relating to prod-webserver (instances, target group, AMI, scaling, VPC, etc.), S3 cloudfront.abc.com bucket, jenkins, OpenVPN, all Seoul assets.
Perhaps I could achieve the goal with 'Organizations' or the 'Control Tower' as well. Could anyone please advise what would be best in my scenario? Is there Better alternative for this ?
The fact that you was to split for billing purposes means you should use separate AWS Accounts. While you could split some billing by tags within a single account, it's much easier to use multiple accounts to split the billing.
The typical split is Production / Testing / Development.
You can join the accounts together by using AWS Organizations, which gives some overall security controls.
Separating workloads and environments is considered a best practice in AWS according to the AWS Well-Architected Framework. Nowadays Control Tower (which builds upon AWS Organizations) is the standard for building multi-account setups in AWS.
Regarding multi-account setups I recommend reading the Organizing Your AWS Environment Using Multiple Accounts.
Also have a look at the open-source AWS Quickstart superwerker which sets up a well-architected AWS landing zone using AWS Control Tower, Security Hub, GuardDuty, and more.
AWS provides a lot information about this topic. E.g. a very detailed Whitepaper about Organizing Your AWS Environment in which they say
Using multiple AWS accounts to help isolate and manage your business applications and data can
help you optimize across most of the AWS Well-Architected Framework pillars, including operational
excellence, security, reliability, and cost optimization.
With accounts, you logically separate all resources (unless you allow something else) and therefore ensure independence between e.g. the development environment and the production environment.
You should also take a look at Organizational Units (OUs)
The following benefits of using OUs helped shape the Recommended OUs and accounts and Patterns for organizing your AWS accounts.
Group similar accounts based on function
Apply common policies
Share common resources
Provision and manage common resources
Control Tower is a tool which allows you to manage all your AWS accounts in one place. You can apply policies for every account, OU, or prohibit regions. You can use the Account Factory to create new accounts based on blueprints.
But still you need to collect a lot of knowledge about these tools and best practices because they're just that. Best practices and recommendations you can use to get started and build a good foundation, but they're nothing you can fully rely on because you may have individual factors.
So understanding these factor and consequences is very important.
What if I delete by mistake my aws API or any other aws ressource that took several weeks/months to build ? Or if a malicious developer get fraudulent acces to my AWS and decide to delete all my hard work ?
Is there a kind of backup AWS make automatically to prevent against these scenarios ?
There is no blanket mechanism for backing up all resources in AWS for this scenario. You need to think of these scenarios and deploy infrastructure accordingly.
Unfortunately this topic is too wide to discuss in one comment.
You can think of preventing these accidental deletions by using IAM's and SCP's.
There are some services like AWS Backup which can help you with getting backups of your persistent data resources.
Refer: https://aws.amazon.com/backup/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc
The way you have asked this question it is difficult to answer. If you could provide a specific scenario, we might be able to better assist. Here are my tips though:
You need to secure your environment with least privileges. Only turn on policies, access, process, etc, that you are using.
Turn on Monitoring with Cloud Watch so you can properly monitor your servers.
Turn on two factor Authentication for your IAM Account. Do not do this for Root. Only use Root to fix any two factor authentication issues.
Use Snapshots, AMIs, etc.
Use Versioning software for all of your code. Put your Lamda, Policies, and any other code or scripts you write in GIT so you don't loose them.
Enjoy
[Not sure this is the correct forum for this question, but I'll give it a shot.]
I'm looking at duplicating an existing solution built on AWS into an AWS China account. From what I've read in AWS' getting started blog post and AWS China's list of services per region, it seems to me that deploying a solution in Beijing or Ningxia using the AWS services we're used to and dependent on would be feasible. But since you cannot create an AWS China account without having a business license (which seems to be a topic in itself, hmm), it seems impossible to actually try things out to get a feel for if there are any differences. I also cannot seem to find any blog posts with testimonies, experiences from developers or architects who've done this, which is surprising.
Basically I want to understand if taking an existing solution built on AWS and setting it up on Chinese infrastructure is straightforward or if I should expect some differences in how things work etc. I know that AWS does not operate these two regions themselves, but through Chinese partner companies. But I'm not sure if the service capabilities, APIs etc are identical (even including the timing of releases of new versions etc).
The only real limitations I can find on the AWS blog is that the free tier is not available, and that EC2 classic instances is not supported. But let's say I have a solution using very stadnard AWS services like Cloudfront, S3, DynamoDB, Lambda, ECS, Elastic Beanstalk, Cognito, KMS etc. Will it be fairly simple to migrate it to an AWS China account or should I expect a struggle?
Regarding the difference, basically AWS China and AWS Global are two seperate cloud and they are not connected to earch other, thus they will have separate Marketplace,Endpoints and ARNs, different service capablities etc. However those differences are not capatured in such details in official AWS documentation.
For example most security related features, landing zone related feature are not available in AWS China. I have tried to customize some AWS global solutions to China, and met lot of issues and challenges, so plug and play won't work here. The best way is to have some parnters or local presence to overcome those challenges especially the team with similar capabilities.
I am new in the AWS Cloud services.
I assigned a project to prepare a new environment in the cloud, to which my team will later migrate their applications. The Stakeholders have come up with some Technical and Business requirements:
They are concerned about the security of the environment, so they have decided to virtually isolate their network from the rest of the customers and rest of the environments in the same AWS Cloud Account
Which AWS Cloud service I could try to use to implement this requirement?
Please let me know if I need to provide more details.
Thank you in advance.
First of all, I would question why the Stakeholders would assign someone with very little AWS experience the task of creating a secure network from scratch in it, and then reveal they are concerned about how secure it will be. (Nothing personal against you, just seems like a strange approach)
Secondly, this is a deep topic, with multiple answers depending upon the specifics of your Technical and Business requirements...
From what I can gather, at a high level you're trying to implement a multi-VPC setup in a single AWS Account.
In short, there are too many scenarios to go into for a StackOverflow answer. The best advice I could give would be to seek advice from an AWS networking/security architect (or consultant) if that is an option for you. They should be able to review your requirements in detail and formulate an appropriate solution.
I'll give you an idea of the sorts of services/resources you should be looking to read up on if you want to implement a secure multi-VPC network in AWS:
VPC peering connections or Transit Gateway to handle routing between VPCs
NACLs to control layer 3 traffic into and out of your VPCs
Security Groups to control layer 3 & 4 traffic into and out of the instances in your VPCs
Having spent a couple of days setting up and configuring a new AWS account I would like to grab an export of the account configuration across all services. I've Googled around for existing scripts, etc, but have yet to find anything that would automate this process.
Primarily this would be as a backup incase the account was corrupted in some way (including user error!) but this would also be useful to document the system.
From an account administration perspective, there are various parts of the AWS console that don't display friendly names for various resources. Being able to cross reference against offline documentation would simplify these scenarios. For example, friendly names for vpc's and subnets aren't always displayed when configuring resources to use them.
Lastly I would like to be able to use this to spot suspicious changes to the configuration as part of intrusion detection. For example, looking out for security group changes to protected resources.
To clarify, I am looking to backup the configuration of AWS resources, not the actual resources themselves. Resource backups (e.g. EC2 instances) is already covered.
The closest i've seen to that is CloudFormer.
That would create a CloudFormation template from your account's resources. Mind that this template would be only a starting point, not meant to be reproducible out-of-the-box. For example, it won't log into your instances or anything like that.
As for the intrusion detection part, see CloudTrail
Check out AWS Config: https://aws.amazon.com/config/
AWS Config records the configuration of AWS resources automatically, allowing you to query and react to configuration changes. As AWS Config stores data on S3, that is probably enough backup, but you can also sync the bucket elsewhere for paranoid redundancy.