Data -- A perfect figure and shows the characteristics of any individual. When it comes to security, it's a null hypothesis statement " The data is secured ". We are believing it, the statement is true and how sure the organizational data is secured with the cloud.
Even though there is a security concern in all the three models of cloud services --
SaaS vs PaaS vs IaaS models
. How can we handle the data secured with High-reliability, maintain resource and cost-effective?
Google values customers data and commits to uphold trust to the highest degree. see terms of service and security and privacy. As Google puts security to the forefront, the onus is on the user to ensure that they are using the necessary tools (Provided by google) and steps to secure resources. Google Infrastructure Security Design will explain what is managed on their part, but implementing other means of securing resources she be done on the clients part as well.
Related
I'm building a simple analytic service that needs to work for multiple countries. It's likely that someone from a restricted jurisdiction (e.g. Iran) hits the endpoint. I am not offering any service that would fall under sanctions-related restrictions, but it seems like Cloud Run endpoints do not allow traffic from places like Iran. I tried various configurations (adding a domain mapping, an external HTTPS LB, calling from Firebase, etc) and it doesn't work.
Is there a way to let read-only traffic through from these territories? Or is there another Google product that would allow this? It seems like the Google Maps prohibited territory list applies to some services, but not others (e.g. Firebase doesn't have this issue).
You should serve traffic through Load Balancer with Cloud Armour policy. Cloud Armour provide a feature for filtering traffic based on location.
Following Coursera Architecting with Google Kubernetes Engine for switching to Service Account.
It says create and download a key file and authenticate using the key. Is this the common way in GCP? There will be many keys created by developers and downloaded to many laptops or servers scattering the keys in many places, which seems to be not secure manner.
Answering your question, yes. The service accounts are the common way to authenticate in GCP.
There are two different service account types, and the recommendation is to use the second one:
User Managed Service Accounts: to authenticate you will then need a “password” that comes in the form of Service Account Key (json file), and if you leak the service account key, the service account can be considered compromised.
Using keys implies that you are in charge of their lifecycle and security, and it’s a lot to ask because:
You need a robust system for secrets distribution.
You need to implement a key rotation policy.
You need to implement safeguards to prevent key leaks.
Google Managed Service Account: Google Managed Service Accounts, are SAs for which you don’t need to generate keys and your applications can just assume their identity. No keys are involved: the VM will continuously request short lived authorization tokens from the metadata service.
Documentation
NO, no and no, don't use service account key file. As you smell it, you are right, it's a terrible thing for the security.
Today, there are several way to prevent the service account key usage, even if, in some corner case, you need them.
I have wrote bunch of articles on that topics:
the limits
the service account credential API
and a fight against a Google dev advocate and one of his article
Because YES, even Google tutorials, courses, documentation (...) promote that bad practice for years and continue. It was my nightmare in my previous company, and I increased my knowledge and skill to prevent key usage and find workarounds. Let me know your use case, I will try to help your the most
Which AWS services are GDPR ready? Can I build and run GDPR compliant applications on AWS?
All AWS Services can be used in compliance with GDPR
Many requirements under the GDPR focus on ensuring effective control and protection of personal data. AWS services give you the capability to implement your own security measures in the ways you need in order to enable your compliance with the GDPR, including specific measures such as:
Encryption of personal data
Ability to ensure the ongoing confidentiality, integrity, availability, and resilience of processing systems and services
Ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident
Processes for regularly testing, assessing, and evaluating the effectiveness of technical and organizational measures for ensuring the security of processing
This is an advanced set of security and compliance services that are designed specifically to handle the requirements of the GDPR. There are numerous AWS services that have particular significance for customers focusing on GDPR compliancea and AWS has 500+ features and services focused on security and compliance.
For more information, have a look at the AWS GDPR Center.
The AWS Shared Responsibility Model and GDPR
AWS has a shared responsibility model with the customer and this doesn't change under GDPR. AWS is responsible for securing the underlying infrastructure that supports the cloud and the services provided; while customers, acting either as data controllers or data processors, are responsible for any personal data they put in the cloud.
You can find more information about the shared responsibility under GDPR in the AWS Security Blog.
One thing I dislike about Google Cloud Platform (GCP) is its less baked-in security model around roles/service accounts.
Running locally on my laptop, I need to use the service account's key specified in a JSON file. In AWS, I can just assume a role I have been granted access to assume (without needing to carry around a private key). Is there an analogue to this with GCP?
I am going to try and answer this. I have the AWS Security Specialty (8 AWS certifications) and I know AWS very well. I have been investing a lot of time this year mastering Google Cloud with a focus on authorization and security. I am also an MVP Security for Alibaba Cloud.
AWS has a focus on security and security features that I both admire and appreciate. However, unless you really spend the time to understand all the little details, it is easy to implement poor/broken security in AWS. I can also say the same about Google security. Google has excellent security built into Google Cloud Platform. Google just does it differently and also requires a lot of time to understand all the little features / details.
In AWS, you cannot just assume a role. You need an AWS Access Key first or be authenticated via a service role. Then you can call STS to assume a role. Both AWS and Google make this easy with AWS Access Keys / Google Service Accounts. Whereas AWS uses roles, Google uses roles/scopes. The end result is good in either platform.
Google authentication is based upon OAuth 2.0. AWS authentication is based upon Access Key / Secret Key. Both have their strengths and weaknesses. Both can be either easy to implement (if you understand them well) or a pain to get correct.
The major cloud providers (AWS, Azure, Alibaba, Google, IBM) are moving very fast with a constant stream of new features and services. Each one has strengths and weaknesses. Today, there is no platform that offers all the features of the others. AWS today is ahead both in features and market share. Google has a vast number of services that outnumber AWS and I don't know why this is overlooked. The other platforms are catching up quickly and today, you can implement enterprise class solutions and security with any of the cloud platforms.
Today, we would not choose only Microsoft or only Open Source for our application and server infrastructure. In 2019, we will not be chosing only AWS or only Google, etc. for our cloud infrastructure. We will mix and match the best services from each platform for our needs.
As described in the Getting Started with Authentication [1] page, for service accounts it is needed the key file in order to authenticate.
From [2]: You can authenticate to a Google Cloud Platform (GCP) API using service accounts or user accounts, and for APIs that don't require authentication, you can use API keys.
Service and user accounts needs the key file to authenticate. Taking this information into account, there is no manner to locally authenticate without using a key file.
Links:
[1] https://cloud.google.com/docs/authentication/getting-started
[2] https://cloud.google.com/docs/authentication/
We are developing a custom application, API architecture, related services and processes, based on a LAMP stack and all relevant AWS services: Elastic Beanstalk, EC2, S3, ELB, RDS, API Gateway, Lambda, SNS etc. We would propose to manage the app and all related infrastructure for a flat monthly rate to our client base. We would handle all payment details with Amazon directly for all clients. We are essentially building out a multi-tenant application on AWS. We want to be able to service the AWS infrastructure for potentially 1000s of accounts/clients.
Here is the question: What are the pros/cons of:
Option A) hosting all services in a single AWS account using carefully structured IAM roles, users, and permissions, and co-mingling customer data while insuring logical and secure separation of customer data within the account?
- VS -
Option B) creating a unique AWS for each account each client, and manage each account via a local profile. In this approach, all data is fully segregated, but we have to manage common activities (user management, code deployment, operations) across 100s of discrete accounts. There is a data security advantage, but it is feasible to manage that many accounts? Any tools or processes for doing it this way? Each company technician would need a login across every account.
The isolation of option B improves security for each client, as any potential security breach would be limited to a single account. But would code deployments be a nightmare? But what about configuration management?
Is there an account federation service that would help manage option B? Or am I nuts for even considering option B?
Lots to think about, but IMO, in this instance, security trumps all other concerns and that would make me choose option B with the little I know about your setup.
Just think what would happen to your business if the 'master' account was compromised - by a hacker (internal or external) - your clients would be running for the door.
Having lots of accounts to manage is an obstacle, but if treat your infrastructure as code, your code-deployments and everything else can be automated - with 1000s of accounts you will have no choice but to put those systems in place.