I keep reading about how Azure Managed Identities are the way to go to secure access to Azure resources, and i totally get the convenience and level of security they offer. But i often worry that at the same time they leave open the possibility that any vulnerability to any application that is running within my resource can then leverage that identity to do things that i may not want it to do, not just the application i want to give access to that resource.
This method of securing things while convenient has always felt awkward. Its like if i need to give a friend of mine access to my apartment to watch my dog while im on vacation, instead of giving my friend my keys i instead just slip the keys through the mail slot and they have 4 other roommates. (lets pretend that these keys are soul-bound to everyone that lives there and cannot be stolen)
Is it possible to combine both Managed Identities with traditional credentials to consume resources?
A specific example might be, i have a JAVA spring based application that consumes Azure Database for MySQL that i have deployed into a Kubernetes environment. I am using a sidecar container with NGINX to provide external HTTP access to that application. Using a pod-managed identity here implies to me that both the JAVA application and NGINX will have access to the database, when i only want my application to be the one that has access. Certainly there are other architectural approaches that i could take in this example but more trying to outline my concerns with managed identities alone.
Related
I'm developing an application and I want it to be open-source.
In production, the application is using the Azure Key Vault Service only to store the database connection string. The connection string is stored on an Environment variable of the production server.
In local, I'm using an InMemory Database from EntityFramework. No sensitive data is accessible.
In production too, the application is using the Azure App Configuration Service. While being able to update the configuration of an already running application, it also allows me to centralize the configuration data of my application.
In local, I'm using the Azure App Configuration Service too. The READ-ONLY connection string is stored in my User Secrets.
And that's the point I'm struggling with. Is it considered a bad practice to share the READ-ONLY App Configuration Connection String on a Github or something else public ? Even if I don't store any sensitive data ?
The Key Vault Service is especially designed to safety store the sensitive data, so in theory the App Configuration Service doesn't have any sensitive data available.
But I can't find any relevant documentation on that topic, and the fact that every tutorials I can find are storing the connection string in the user secrets is warning me. How can I share my configuration in a safety way to make my project open-source ?
From security perspective you are violating principle of least privilege, giving read access to public that they don't need.
This could raise several risks:
You or someone else maintaining the App Configuration might "forget" about public read access and put vulnerable data there
An attacker might exploit a security bug in App Configuration itself and escalate read-only permission to read-write, which would not happen if they didn't have read-only access in the first place
You might think that probability of that happening is marginal (which is probably the case), but it is there and in security we always stay on the safe side - that's why we have the principle mentioned and it is indeed generally considered bad practice to violate it.
Finally, we always need to choose between usability and security, so in the end you might willfully agree to slightly less security if this makes your life easier and potential trouble from the risks does not scare you.
In case you would like not to expose the connection string you can think about:
abstracting configuration fetching in a similar way you did for secrets, so that production app would use App Configuration while for local development you can use InMemory database
replacing connection string with Terraform script so that you or any other developer can spin up and populate a dedicated App Configuration instance for local development purposes
In a hobby side project I am creating an online game where the user can play a card game by implementing strategies. The user can submit his code and it will play against other users strategies. Once the user has submitted his code, the code needs to be run on server side.
I decided that I want to isolate code execution of user submitted code into an AWS lambda function. I want to prevent the code from stealing my AWS credentials, mining cryptocurrency and doing other harmful activity.
My plan is to do following:
Limit code execution time
Prevent any communication to internet & internal services (except trough the return value).
Have a review process in place, which prevents execution of user submitted code before it is considered unharmful
Now I need your advice on how to achieve best isolation:
How do I configure my function, so that it has no internet access?
How do I configure my function, so that it has no access to my internal services?
Do you see any other possible attack vector?
How do I configure my function, so that it has no internet access?
Launch the function into an isolated private subnet within a VPC.
How do I configure my function, so that it has no access to my internal services?
By launching the function inside the isolated private subnet you can configure which services it has access to by controlling them via the security groups and further via Route Table this subnet attached including AWS Network ACLs.
Do you see any other possible attack vector?
There could be multiple attack vectors here :
I would try to answer from the security perspective in AWS Services. The most important would be to add AWS Billing Alerts setup, just in case there is some trouble at least you'll get notified and take necessary action and I am assuming you already have MFA setup for your logins.
Make sure you configure your lambda with the least privilege IAM Role
Create a completely separate subnet dedicated to launching the lambda function
Create security for lambda and control this lambda access to other services in your solution.
Have a separate route table for the subnet where you allow only the selected services or be very specific with corresponding IP addresses as well.
Make sure you use Network ACLs to configure all the outgoing traffic from the subnet by adding ACL as well as an added benefit.
Enable the VPC flow logs and have the necessary Athena queries with analysis in place and add alerts using AWS CloudWatch.
The list can be very long when you want to secure this deployment fully in AWS. I have added just few.
I'd start by saying this is very risky and allowing people to run their own code in your infrastructure can be very dangerous. However, that said, here's a few things:
Limiting Code Execution Time
This is already built in to Lambda. Functions have an execution limit on time which you can configure easily through IaC, the AWS Console or the CLI.
Restricting Internet Access
By default Lambda functions can be thought of as existing outside the constraints of a VPC for more applications. They therefore have internet access. I guess you could put your Lambda function inside a private subnet in a VPC and then configure the networking to not allow connections out except to locations you want.
Restricting Access to Other Services
Assuming that you are referring to AWS services here, Lamdba functions are bound by IAM roles in relation to other AWS services they can access. As long as you don't give the Lambda function access to something in it's IAM role, it won't be able to access those services unless a potentially malicious user provides credentials via some other means such as putting them in plain text in code which could be picked up by an AWS SDK implementation.
If you are referring to other internal services such as EC2 instances or ECS services then you can restrict access using the correct network configuration and putting your function in a VPC.
Do you see any other possible attack vector?
It's hard to say for sure. I'd really advise against this completely without taking some professional (and likely paid and insured) advice. There are new attack vectors that can open up or be discovered daily and therefore any advice now may completely change tomorrow if a new vulnerability is discovered.
I think your best bets are:
Restrict the function timeout to be as low as phyisically possible (allowing for cold starts).
Minimise the IAM policy for the function as far as humanly possible. Careful with logging because I assume you'll want some logs but not allow someone to run GB's of data in to your CloudWatch logs.
Restrict the language used so you are using one language that you're very confident in and that you can audit easily.
Run the lambda in a private subnet in a VPC. You'll likely want a seperate routing table and you will need to audit your security groups and network ACL's closely.
Add alerts and VPC logs so you can be sure that a) if something does happen that shouldn't then it's logged and traceable and b) you are able to automatically get alerted on the problem and rectify it as soon as possible.
Consider who will be reviewing the code. Are they experienced and trained to spot attack vectors?
Seek paid, professional advice so you don't end up with security problems or very large bills from AWS.
I am planning to have multiple azure mobile service instances, so the first requirement I have is to share the access token of authenticated user across different app instances. I found this article https://cgillum.tech/2016/03/07/app-service-token-store/ that states that right now we can not share the tokens as it is stored locally on machine, and placing it to blob storage is not recommended for production apps. What is the possible solution I have at this time?
I have read the blog you mentioned about App Service Token Store. As mentioned about where the tokens live:
Internally, all these tokens are stored in your app’s local file storage under D:/home/data/.auth/tokens. The tokens themselves are all encrypted in user-specific .json files using app-specific encryption keys and cryptographically signed as per best practice.
I found this article https://cgillum.tech/2016/03/07/app-service-token-store/ that states that right now we can not share the tokens as it is stored locally on machine.
As Azure-runtime-environment states about the Persisted files that an Azure Web App can deal with:
They are rooted in d:\home, which can also be found using the %HOME% environment variable.
These files are persistent, meaning that you can rely on them staying there until you do something to change them. Also, they are shared between all instances of your site (when you scale it up to multiple instances). Internally, the way this works is that they are stored in Azure Storage instead of living on the local file system.
Moreover, Azure app service would enable ARR Affinity to keep a client subsequent requests talking to the same instance. You could disable the session affinity cookie, then requests would be distributed across all the instances. For more details, you could refer to this blog.
Additionally, I have tried to disable ARR Affinity and scale my mobile service to multiple instances, then I could always browser https://[my-website].azurewebsites.net/.auth/me to retrieve information about the current logged-in user.
Per my understanding, you could accomplish the authentication/authorization by yourself to use auth middle-ware into your app. But, this requires more works to be done. Since the platform takes care of it for you, I assume that you could leverage Easy Auth and Token Store and scale your mobile service to multiple instances without worrying about anything.
Currently our DB works in customer's local network and we have client app on C# to consume data. Due to some business needs, we got order to start moving everything to Azure. DB will be moving to Azure SQL.
We had discussion about accessing DB. There are two points:
One guy said that we have to add one more layer between our app (that will be working outside Azure at end-user PCs) and SQL Azure. In other words he suggested adding API service that will be translated all requests to DB, i.e. app(on-premises) -> API service (on Azure)-> SQL Azure. This approach looks more reliable and secure, since we are hiding SQL Azure behind facade of API service and the app talks to our API service only. It looks more like a reverse proxy. Obviously, behind this API we can build more sophisticated structure of DBs.
Another guy suggested connecting directly to DB, i.e. app(on-premises) -> SQL Azure. So far we don't have any plans to change structure of DB or even increase count of DBs. He claims it more simple and we can secure our connection the same way. Having additional service that just re-translates our queries to DB and back looks like wasting time.In the future, if needed, we would add this API.
What would you select and recommend, and why ?
Few notes:
We are going to use Azure AD to authenticate users.
Our application will be moving to Azure too, but later (in 1-2 years), we have plans to create REST API and move to thin client instead of fat client we have right now.
Good performance is our goal, we don't want to add extra things that can decrease it, but security is our most important goal as well.
Certainly an intermediate layer is one way to go. There isn't enough detail to be sure, but I wonder why you don't try the second option. Usually some redevelopment is normal. But if you can get away without it, and you get sufficient performance then that's even better.
I hope this helps.
Thank you.
Guy
If your application is not just a prototype (it sounds like it is not), then I advise you to build the intermediate API. The primary reasons for this are:
Flexibility
Rolling out a new version of an API is simple: You have either only one deployment or you have something like Octopus Deploy that deploys to a few instances at the same time for you. Deploying client applications is usually much more involved: Creating installers, distributing them, making sure users install them, etc.
If you build the API, you will be able to make changes to the DB and hide these changes from the client applications by just modifying the API implementation, but keeping the API interfaces the same. Moving forward, this will simplify the tasks for your team considerably.
Security
As soon as you have different roles/permissions in your system, you will need to implement them with DB security features if you connect to the DB directly. This may work for simple cases, but even there it is a pain to manage.
With an API, you can implement authorization in the API using C#. Like this, you can build whatever you need and you're not restricted by the security features the DB offers.
Also, if you don't take extra care about this, you may end up exposing the DB credentials to the client app, which will be a major security flaw.
Conclusion
Build the intermediate API. Except you have strong reasons not to. As always with architecture considerations, I'm sure there are cases where the above points don't apply. Just make sure you understand all the implications if you decide to go the direct route.
I am having a hard time understanding Windows Azure service bus and access control concepts. In layman's terms, what are they? What are they used for?
The Service Bus component of Windows Azure is meant to handle the problems arising from services that are living in multiple networks. Basically, a service bus just makes it appear as if your code is running on a single machine, while in reality it could be running anywhere within the Azure datacenters.
Access Control lets you use "federated authentication for your service based on a claim-based RESTful model. (Sorry, copy&Paste from an O'Reilly book about Azure!)
Basically, when you create an Azure site, application or service, it could be running on any of the thousands of systems within the datacenter. And each of those systems has it's own IP address, it's own network, memory, processor and whatever more. To let them collaborate and to appear as a single system, these two services have been created.
If you want to learn more about Azure, this would be a good moment to buy a book! :-)
Azure is quite complex and service buses and access control are a bit more advanced topics.
Service Bus is a solution for the integration between multiple applications whether they are hosted on the same infrastructure or even spread along multiple infrastructure or/and Cloud Computing provider. If you search more in the internet you might find a lot about EAI (Enterprise application integration) here is my blog post about this topic:
http://hhaggan.wordpress.com/2013/03/07/introduction-to-enterprise-application-integration-eai/
and here another that I hope that helps you understand better what is the service bus:
http://hhaggan.wordpress.com/2013/03/09/introducing-service-bus/
in another words, it is a messaging platform that helps you communicate with multiple applications, softwares or services no matter what programming language they are written with or on which os or platform they are hosted on. you will feel its effect specially when you work on connecting multiple nodes together, I don't mean 5 or 6 nodes but 10 and above.
Certainly there are several types of service bus, whether they are based on relayed messaging service or brokered messaging service, each one of them has several uses, its purpose and way of working.
For the Access control, this is so easy, it is a way of authentication and authorization for your application using third parties, It is a claim based identity that you can do the required authentication through the third party database. you wont need to build everything from scratch in your database. this helps a lot during development and I believe that this can help a lot in social media marketing and branding because of the use of facebook, twitter during the authentication.