I'm following the guide here to setup Application Insight telemetry on a frontend web form. I wish to use the snippet-based setup. I notice, however, that it requires me to embed the connection url in the html page. Is that a security issue?
There would be nothing to stop a malicious user from using browser dev tools to grab that url and then send any API calls to that url. Should I be concerned about this? If so, what is the recommended approach for securing this connection url.
... what is the recommended approach for securing this connection url.
There is none. For now you have to accept it is visible somehow. See also this open issue regarding the topic
Should I be concerned about this?
Not so much. The instrumentation key cannot be used to read any telemetry. However, it could be used to send bogus telemetry to your application insigths resource. This could lead to higher costs depending on the amount of data ingested and it could clutter your logs, possible masking possibly relevant telemetry.
Unless the application is hosted on a vnet integrated resource you cannot restrict access to application insights resource. If it is, then you can set application insights to deny queries or ingestion from external sources in the network isolation setting.
https://learn.microsoft.com/en-us/azure/azure-monitor/logs/private-link-security
So even if someone gets the url they cannot access.
Related
I am hosting our app on Azure and the Insights logs shows that all requests coming into the application are logging 0.0.0.0 as the client_IP.
For example, this kusto query:
requests
| where client_IP != '0.0.0.0'
...returns no results.
As the app uses the AspNetCoreRateLimit package to rate limit user requests for one particular endpoint, the net effect appears to be that all users are rate limited, rather than on a per user basis.
My understanding is that if Insights can't get the client IP address, then our code (and any NuGets it uses) will not be able to, either.
Is it a fair assumption that it is Azure which is preventing both Insights and our code from acquiring the client IP address? If that is a possibility, how could I confirm that?
Is it a fair assumption that it is Azure which is preventing both Insights and our code from acquiring the client IP address? If that is a possibility, how could I confirm that?
App Insights doesn't store the ip by design:
By default IP addresses are temporarily collected, but not stored in Application Insights.
...
This behavior is by design to help avoid unnecessary collection of personal data. Whenever possible, we recommend avoiding the collection of personal data.
...
To enable IP collection and storage, the DisableIpMasking property of the Application Insights component must be set to true. This property can be set through Azure Resource Manager templates or by calling the REST API.
So your code should still be able to collect ip addresses.
We are looking at using webhooks from various vendors outside our network. They would publish the event to us. We would be the webhook listener/receiver, not pushing the events. We have done proof of concept of creating an Azure Function to receive the event. From the research we have done most have the security of passing a sha1/sha256/sha512 hash for us to verify they are who we want to receive the events. This all worked as expected with the POC Azure Function.
From a enterprise network security standpoint is there anything else available? The process above puts the security in the function. I'm sure our Network Security group would not want us to have 10 functions, one for each vendor to worry about the security. I've read about whitelisting of IP's that would be sending the events but most of our vendors are Cloud based so I'm not sure how readily that would be available. Maybe one function to validate all events that come in then let pass through? Would that be an acceptable solution? Azure API Gateway or API Management able to address somehow? Any other network type of product that handles webhook security specifically?
Any insight or link to information most appreciated.
Thanks.
Wow, that's really really so open conversation.
You can use Azure Front Door with the Web Application Firewall attached to it. So any SQL injection, DDoS or similar attacks can be prevented by AFD and WAF.
However, I would say the securest way is to put IP restriction as well. So you need to force your vendor to get their IP address. That can be multiple maybe hundreds. But that doesn't matter. You can implement CIDR IP address format so you can cover all network. And you can easily set these IP address restriction during the CI/CD pipeline with Azure PowerShell script.
You can also useAPI Management in front of Azure Functions and you can create access restriction policies. You can either restrict IP based or JWT based. APIM might be a little bit pricey tho.
https://learn.microsoft.com/en-us/azure/api-management/api-management-access-restriction-policies
You can also create advanced policies with APIM
https://learn.microsoft.com/en-us/azure/api-management/api-management-advanced-policies
Apart from that, the AFD & WAF and IP restriction are on the network layer. But you can also implement token-based authentication on your code side.
https://learn.microsoft.com/en-us/azure/app-service/overview-authentication-authorization
You can either you Azure Active Directory, IdentityServer or JWT for this.
Good luck!
I have researched around a bit where all of the captive portals are little bit complicated in terms of configuration.
I dont need AAA , I would just show a webpage where user will be click yes accept terms and then it will redirected.
I am using ignite cloud controller to manage the access points.
Implementing a service where I would like fetch SSID from a repository to match incoming SSID and then redirect based on the SSID.
I am trying to build something externally. My networking skills are pretty new.
I am confused how to get IPAddress and Necessary details from the access point there is an option in ignite cloud controller where I can specify the external settings for captive portal. (Like If my captive portal is running on remote IP, I know I can capture request incoming from access point. How? Can I build a normal web service to do that?)
I think it is straightforward implementation but little guidance is required.
I solved the above by creating a simple web service which filters the request sent from the ACCESS POINT.
There was an option in ignite cloud where I could redirect to my web-service
Once AP redirect I have to set variables in the request forwarding it back to AP with res=success.
Then it will allow me to browse web as expected.
Thanks
I am implementing OData using ASP.NET Web API 2.2. These are deployed as Azure Web roles in different Azure Data centers where data is present in SQL Azure DBs. If there is a request coming from the user, the request has to be redirected to a particular web role deployed in based on the user details.
I am still exploring Azure Traffic Manager capabilities. Is it the way to do it in Azure? or what is the right approach for such scenarios in Azure?
This is not possible using Azure Traffic Manager. Traffic Manager simply does DNS resolution based on the policy (perf, round robin, failover) you choose.
If you want to intelligently route customers based on some logic then I would suggest:
First, are you sure you want to do this? A key tenant of a highly scalable and available service is that a request can be served by any instance/deployment, and it is more important to get the request to the fastest deployment (ie. the perf profile for WATM). There are valid reasons to need to direct users to a specific service, but I would suggest taking a hard look at this design requirement.
You could use ARR or URL Rewrite to internally fetch data from the correct deployment. This may have perf implications, but would be easy to implement.
As Brendan mentioned in a comment, you could have a thin web API layer that just does a 302 redirect to send the user to the correct deployment.
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.