To who it may concern,
I am looking to move more of our applications that the company uses to azure. I have found that Remote App will allow people to us the apps I have allowed via the Remote App. The application which will be used is linked to a database which is on site, I am just worried about people being able to access this database as it will contain important data which cant be leaked. I am trying to work out what are some security precautions which could be taken to prevent the data from being viewed by the wrong people. I have seen app locker to stop applications on the virtual machine from being accessed. Any other security suggestions would be greatly appreciated.
You should be fine. Remote app is running remotely - meaning that theres no way of getting to the connection string (reverse engineering). Access to the app is also ensured by AAD login. The database should be protected as well with AD credentials. Also, adding a service tier that fronts the database would provide a facade.
Related
I've got a rather unwieldy legacy intranet app that does a lot of file manipulations across multiple network shares (file reads, moves, deletes, creates directories, etc) and I want to set up a preproduction instance. Currently the app pool is running under a domain account that has been granted access to all these scattered directories. I'm wondering if running a second instance of the site (different server) using the same domain account would be an issue.
This doesn't seem to be an easy question to formulate in a way to get a useful answer out of google. Anyone have any experience doing this? I would rather not have to create more accounts and track down all the locations that would require added permissions if I don't have to.
The aim to set different application pool identity for different application pools is to restrict the limit for application pool. Independent application pool will isolation NTFS permission from accessing the files that the web app shouldn't reach. Just in case the server are under vulnerability attack.
Of course, if you are hosting your web apps in a isolated network environment, you could share your domain account for multiple application pools.
As Lex said, consult your network administrator would get more practical answer.
I have been researching for a couple days and looking at pluralsight courses but I Can't seem to find a decent answer on how to setup a proper Azure infrastructure.
I have a client app, api backend, and a database as a core of my overall application. I know I need 2 different Web App services and an SQL database.
I also have a need to only allow access to all 3 from our company's IP address.
I'm getting lost with all the VNET and VPN talk and I am wondering if that is even required. Is it considered good to do IP restrictions and call it a day? Should I add an Application Gateway infront of the client application none the less?
If VNETs are required, is it a must to do site-to-site? (don't think we have the authority to do that) If not, how do we access the backend services like the database and API if everything is locked down?
Any help is appreciated because there is too much information and I can't seem to make sense of any of it.
Thanks
It depends a lot on both the purpose of your client application, web application and database, as well as the capabilities that currently exist within your organisation. Have you had a look at the references architectures Microsoft has as a starting point ?
If you are looking at a fairly simple application, deployed to Azure with minimal internal only use, then use something like this reference architecture: https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/vpn. You can actually simplify that a little further by removing the load balancers etc if you think traffic will be generally low.
If you are looking for an external application that can only be managed internally, you should adopt something similar to this reference architecture: https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/n-tier/n-tier-sql-server. Maybe even add a VPN component to the management jump box similar to this architecture: https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/vpn.
Even this, however may be too complicated for your use case. If your application is pretty basic, is secured using username/password or identity federation, and has low risk data associated with it, then just the basic web application architecture would do fine, just read through the various considerations here: https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/app-service-web-app/basic-web-app
My company developed a business suite which is not a SaaS platform now. We're in beta mode now and will launch V2 within next 2 months. Currently we are creating instance for interested clients (free for a year) but getting questions that their data is secured. Now, my question is, since we are creating their instances on our Azure platform,is there a way to make sure that we won't be able to access their data anyway?
Thanks in advance!
Some of the security setup you can configure and present are -
Configure firewall rules to restrict access to db based on the originating IP address of each request. You can share the firewall settings that only specific Virtual Machines/Computers have access to the client's database.
Authentication to the database. We can remove any SQL authentication(username/password based) and configure only Azure Integrated security for the applications accessing the database. Best practice would be using service accounts to access the db. You can showcase this too.
The Point to Site VPN provided by Azure is great and allows me to build a relatively inexpensive "corporate" network for my small, all remote user business. The only issue that is stopping me is figuring out how to do individual user management during the off-boarding process. It appears that by using the pre-shared keys with no other authentication that the only way to off-board a employee and remove their VPN access would be to re-generate all the keys (root and client). Am I missing something, is there some other means to manage cutting access to a user that leaves the company?
Thanks in advance.
I'm currently performing a research on cloud computing. I do this for a company that works with highly private data, and so I'm thinking of this scenario:
A hybrid cloud where the database is still in-house. The application itself could be in the cloud because once a month it can get really busy, so there's definitely some scaling profit to gain. I wonder how security for this would exactly work.
A customer would visit the website (which would be in the cloud) through a secure connection. This means that the data will be passed forward to the cloud website encrypted. From there the data must eventually go to the database but... how is that possible?
Because the database server in-house doesn't know how to handle the already encrypted data (I think?). The database server in-house is not a part of the certificate that has been set up with the customer and the web application. Am I right or am I overseeing something? I'm not an expert on certificates and encryption.
Also, another question: If this could work out, and the data would be encrypted all the time, is it safe to put this in a public cloud environment? or should still a private cloud be used?
Thanks a lot!! in advance!!
Kind regards,
Rens
The secure connection between the application server and the database server should be fully transparent from the applications point of view. A VPN connection can connect the cloud instance that your application is running on with the onsite database, allowing an administrator to simply define a datasource using the database server's ip address.
Of course this does create a security issue when the cloud instance gets compromised.
Both systems can live separately and communicate with each other through a message bus. The web site can publish events for the internal system (or any party) to pick up and the internal system can publish events as well that the web site can process.
This way the web site doesn't need access to the internal database and the internal application doesn't have to share more information than is strictly necessary.
By publishing those events on a transactional message queue (such as MSMQ) you can make sure messages are never lost and you can configure transport level security and message level security to ensure that others aren’t tampering messages.
The internal database will not get compromised once a secured connection is established with the static Mac ID of the user accessing the database. The administrator can provides access to a Mac id through one time approval and add the user to his windows console.