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.
Related
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.
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.
We're currently having an issue where when someone tries to access our TFS server via Visual Studio, they're hit with an Error TF30063: You are not authorized to access
The TFS server is on a different domain to what the client machines trying to connect are on. There is a domain trust between the two and other shared resources work fine.
I have found that it does temporarily work if you open up an RDP (remote) connection to the server in the background and login using your local domain credentials. After leaving your remote session connected and trying to connect again via Visual Studio, it works fine.
Another thing to point out which indeed would be related is, looking at the Administrator group permissions on the TFS server it does not resolve the usernames of the users in the list until they initiate an RDP connection atleast once after a reboot has occurred. Instead it shows their SID.
Things I’ve tried so far are;
Adding Windows and Generic Credentials to the Credential Manager on the TFS server for their domain accounts. I thought it might be an issue with the server not caching their credentials which meant an RDP connection needed to exist each time.
Enabling Windows Authentication in IIS
Adding the path to Trusted Sites in Internet Options
Enabling Network access: Allow anonymous SID/Name translation in Group Policy for the machine.
Creating a registry key under HKLM\System\CurrentControlSet\Control\Lsa called TurnOffAnonymouseBlock and set to 1 which essential is what the GP above does.
None of these however have seemed to fix the issue.
Any suggestions would be greatly appreciated!
If there is a domain trust in place, you should just add the users AD account that they log into their machine with, as a valid user in TFS.
For example, if TFS is in Domain A, and the user's laptop is in domain B (and they login to their laptop with a domain B account), then you need to ensure that Domain A trusts Domain B (either a two-way trust, or one way with A trusting B). Then you just need to make sure to add the user's domain B account as a TFS Contributor for example, and they should be able to access TFS without doing anything special.
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.
Scenario: We have our dedicated servers hosted with a hosting provider. They are running web apps, console apps along with the database which is Sql Server Express edition.
The applications encrypt/decrypt the data to/from the DB. We also store the keys in their server. So theoretically, the hosting provider can access our keys and decrypt our data.
Question: How we can prevent the hosting providers to access our data?
We don't want hosting provider's users to just log into Sql Server and see the data.
We don't want an un-encrypted copy of database files in the box.
To mitigate no. 1: Encrypting app.configs to not store plain text DB username and password.
To mitigate no. 2: Turn on EFS on Sql Server data folder. We could use TDE but the Sql Server is Web Edition version and the hosting company is going to charge us a fortune to use Enterprise Edition.
I'd really appreciate if you guys have any suggestions about above.
You can help mitigate it, but prevention is probably impossible.
It's generally considered that if an attacker has physical access to the machine, they own everything on it.
If this is a concern, you should consider purchasing a server, a virtual server, or using a colocation center and providing your own machine or hosting it yourself entirely.
When you purchase a server, virtual server, or colocate your own hardware, the service provider doesn't have an account on your OS. If you use an encrypted file system, and only access your box via SSH (SSL/TLS), then they will not be able to easily access any data on your computer that isn't being sent out to the network.
The only fool proof way is to have your own hardware in your own secure location and bring the network to your box.
It's possible to do database encryption such that the client does the decryption (though if your indexes are sorted, the server obviously needs to be able to figure out relative order of things in the index). I can't think of a link off the top of my head. However, if the client is the web app, there's not much you can do.
There are also various types of homomorphic encryption, but I'm not sure there's anything that scales polynomially. In any case, the overheads are huge.
I'm curious if there's a reason why you don't trust your hosting provider - or is this just a scenario?
If this is something you have to worry about, sounds like you should be looking at other providers. Protecting yourself from your hosting partner seems counterproductive, IMO.