Today, nobody ever questions the importance of security in IT. On the contrary, security measures applied by companies, service providers and users get more and more complicated with each passing day. And this is not without reason, as, unfortunately, the hacking methods are also advancing with speeds which sometimes seem scary. Never a month goes by without news about a large-scale hack with massive data, identity or money theft.
So, IT service providers have to be at least one step ahead. EPAM Cloud has always been paying a lot of attention to security and has been certified accordingly. Users hosting their infrastructures in EPAM Cloud can rest assured that their data and resources are well protected within the EPAM Cloud security perimeter, as long as they conform to the applicable security requirements. However, the possibilities supported by EPAM Cloud are not limited by EPAM own resources. As a true hybrid cloud, EPAM Orchestrator provides integration with Amazon Web Services (AWS) and Microsoft Azure, external cloud providers with their own resources, services and native functionality.
So, how are you going to stay secure in hybrid infrastructure? What will happen when you stick your head out of the EPAM perimeter? Will you be safe?
To answer all these questions, you first need to decide how far out you are going to get. That directly depends on the tasks you are facing. Let's look at different scenarios of AWS usage.
Running a Virtual Machine in AWS
There may be cases when you have to run your virtual machines in AWS, for example, when you need a very large machine which EPAM Cloud does not support. The flow is rather simple - you activate your project in Amazon, choose the appropriate region, run your virtual machines there... and that's it. EPAM Orchestrator native tools are sufficient to run, start, stop, terminate your virtual machines and to login to them. In this case you are totally safe within the EPAM Cloud security shell, of course, if you follow the applicable security rules.
And do not forget your SSH keys - in AWS they are not a choice but a must. All virtual machines in AWS are to be run with an SSH key, as it is a mandatory component of your login sequence.
Using AWS Services
Amazon has dozens of cloud services, and your project may need some of them once in a while. EPAM Orchestrator has a solution for this case as well. The important thing is that you do not actually have to run virtual machines in AWS, you only need to have your project activated in Amazon. No machines - no bills in the end of the month, less costs for your project. What you need is access to the AWS Management Console which is granted with a single CLI command:
or2awsmc -p your_project
Make sure that your project is activated in Amazon and that you have the permission to request access to the AWS Management Console. If everything is set up properly, the command returns the link directly opening the AWS Management Console for you. No special credentials are needed, you will login with your EPAM username and password.
The AWS Management Console allows working with all Amazon services. If a service is billed, it will be included in your monthly EPAM Cloud bill. The console opens for one hour which is quite sufficient for small occasional tasks.
IAM User Account
But what if you need to use Amazon constantly? What if temporary access is not enough? Well, we have you covered here as well. What you need is an IAM User account.
IAM (Identity and Access Management) is an AWS feature allowing to control and monitor access to Amazon resources. An IAM User account can be shared between several physical users or be assigned to a script performing certain tasks. With an IAM user account you get constant access to all AWS services and, in addition, automate a lot of their processes by using the Amazon API.
Let's walk through every step of an IAM User management.
In EPAM Cloud, IAM users are created upon a request to the Support Portal. The requestor has to describe the permissions to be assigned to the IAM User and to explain why such permissions are needed. In all cases, requests for IAM User creation are examined by the Security Team who give their approval of such user creation. Or they don't, if the proposed pattern of IAM User account use is not secure enough. Sometimes, the Support Team may suggest that you use temporary access to the AWS Management Console via the native EPAM Orchestrator tools, as your tasks will be completely covered by its capacities.
The default IAM User configuration allows rather broad access to the AWS Services, with the exception of creating new IAM Users and changing security groups (in other words, exposing virtual machines to Internet). Such scope of access, for the most part, is sufficient for the project tasks. However, sometimes the default permissions do not exactly fit your tasks. Such exceptions are handled by the Support Team and Security Team upon request.
In general, the rule of thumb is to explain your IAM User requirements as fully and clearly as you can, so that the Support Team and the Security Team can work out the best solution for you. Within two working days your request will be processed. If IAM User creation is approved for you, you will receive a message containing the link to your IAM User account, your login and temporary password. Changing this password will be a good idea.
There is a number of rules which you need to follow to ensure smooth and proper usage of your IAM User account. First, make sure that all account names correspond to the firstname.lastname@example.org format. Second, verify that all IAM Users are assigned to an UPSA project member or to an auto-user (all unassigned IAM User accounts will be removed after November1, 2016!). If all IAM User accounts correspond to these requirements, you are safe.
However, your IAM User account is not completely set up. To finalize your account settings, you need to set up multi-factor authentication as an additional security measure. You can find step-by-step instructions on setting up MFA in one of our previous blog posts. It's as easy as one-two-three, you only need a telephone or tablet with a barcode reader - and you are good to go. All IAM User accounts with no MFA are blocked after 7 days without preliminary notice, so make sure you have it.
And here comes the important part - the reports. Everybody hates being included into mass mailing and receiving what seems to be spam. But be sure that the number, content and mailing lists of all EPAM Cloud emails are subjected to thorough analysis where literally each word and figure are inspected. As the result, the mailings include only the absolutely relevant and important information.
Once in a week the primary contact persons for every project receive Weekly Security Reports. All parts of them are important, but here we will focus on the IAM Users Report which lists all currently active IAM User accounts created for your project.
Look at the last two columns - Last Access Date and On Project. We do recommend keeping IAM User accounts only if you need constant access to AWS, so if no activity has been detected for a month, such account is, probably, not needed anymore. Such abandoned accounts are removed with prior notification to the account owner. Another thing is that the IAM User account is not automatically removed if the project member leaves the project. This is what the On Project column is for. Remove the IAM User accounts if your project no longer needs them. The message contains the CLI command which removes the IAM User - just copy and paste. When the next report comes in, check your IAM Users again. This way, you will have them under control.
Nowadays, we have to observe dozens of security rules every day. Security concerns all aspects of our life, sometimes being annoying, restrictive or even prohibitive. But security rules are never without reason - there is a sad story behind every one. So, do it. Wear your seatbelt. Switch off your phone while flying. Read the security report.