Does azure not have a native transactional email service which we can make use of? Currently all aspects of my platform are hosted within azure. Just feels silly going off to a 3rd party for such a simple task.
The problem with the email software in the cloud that it there can be the sitation when the Azure security perimeter will block the traffic or mark it as a spam or many other situations. Especially when you do not have the dedicated IP address (in Azure, btw, you can).
I know about three options - i tested first two, and it works:
1) SendGrid partner offering has 25 000 free emails/month. Tutorial. Simplest way.
2) Less simple is to use external SMTP provider and something like System.Net.Mail. It works, but again, should be tested. It is not guaranteed that your server will not be blocked.
3) Set up the mail server and set up the reverse DNS.
I heard that some folks set up the IIS SMTP service. Did not do it by myself, but i expect that it will involve some extra infrastructure efforts.
I would highly recommend you to not place SMTP server inside of the cloud, but instead of that use some external one. But it can be set up and should work.
Related
We have an application that we are hosting in multiple environments in Microsoft Azure. We want to route the traffic based on subdomains, like xxx.mydomain.com should go to the webapp that I have in North Europe and yyy.mydomain.com and zzz.mydomain.com should go to the webapp that I have in the East US.
I know it sounds like simple DNS, but it is more than that. Because:
I need to be able to add or update entries dynamically using code so an API should be available for that.
A normal DNS entry has a 24 hours time to live meaning that if I want to move my app from one environment to another, for up to 24 hours, users will hit both environments.
I expect to have hundreds of thousands of subdomains. Azure DNS has a limit of 25,000 entries.
I've looked into Azure Traffic Manager. It doesn't seem to have an option for traffic based on subdomains.
Also, I've looked at Azure Application Gateway. It seems to be the correct choice and it supports API's, but I cannot find the limits for subdomains.
Any suggestions?
From the criteria, it seems you're looking for a load-balancer/proxy/application-delivery-controller solution that's controllable through an API. I'll add my 5 cents here, as we've just gone through very similar problem. However these are more of a suggestion to look for answers elsewhere then Azure.
Azure
Azure Traffic Manager or Azure Application Gateway have limits which you can't fit in. For example in Azure Application Gateway with 200 rules, you could potentially host only 200 HTTPS site, the moment you need to serve HTTP & HTTPS, you're limited to 100 sites per application gateway. You'd need to split your solution across multiple subscriptions in order to fit subscription wide limits. Also the application gateway API is a bit too convoluted for my liking.
Azure DNS is also a bit problematic, as DNS records can last up to 24 hours. You'd therefore loose the ability to switch/route traffic to a different origin instantly.
Self-hosted
You could look into more old school solutions, run HAProxy or Nginx and programmatically modify their configuration(text files) on the fly and reload the configuration. HAPRoxy also has a socket "API" that can simplify the configuration modification and reload for you.
There's also a new set of service mesh controllers such as Kong, which can run in the cloud natively and are meant for service mesh solutions, however Kong offers a simple API, where you could manage/route traffic easily.
SaaS
If you're into buying this as a Service, Edge Cloud providers such as Cloudflare, Fastly or others are indeed "one big proxy server" and it is possible to configure them programmatically to route traffic to different origins, it's what they do after all.
Azure Application Gateway is indeed perhaps one of the best options for your scenario.
As you already said, it has an api that you could use to dynamically add rules based on your subdomains.
The limits for Application Gateway only allow for 200 rules per gateway.
But you can have 1000 gateways per subscription so if you could chain the gateways, that will give you roughly 200.000 rules.
The Microsoft documentation doesn't show that you can request an increase in these limits but maybe if you ask really nice the might allow it.
Maybe this is not the answer to your question but it might be an answer.
If anyone interested, we've ended up using Azure DNS. We have contacted Microsoft and they confirmed that they can increase the quota to 500,000 which is more than enough for us. :)
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 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
I have a mobile application that communicates with a REST based web-service. The web-service lives behind the firewall and talks to other systems. Currently this web-service requires a firewall port to be opened and a SSL cert generated for each installation. Mobile apps sends login credentials so web-services can login to custom back-end systems.
Recently a customer approached us asking how could we deploy this to 50 offices. As we don't want to say modify every firewall in every office, we're looking for options.. This is a list of possible solutions and my thoughts on each one:
Open firewall port and expose https webservice - This is our current
solution but we dont want to have to contact 50 network admins and explain why we need to do this.
VPN - Too heavy weight, complex and expensive, we only need access
to one server. Does not solve problem as firewall needs to be
modified.
Microsoft Azure Hybrid Connection Manager - This provides a managed
service where the Azure cloud will expose an end point. Azure will
also expect connections from a easy to install application that
lives behind the firewall. When a REST call is made to the cloud
end-point, the request is forward down socket that was initiated by
the software behind the firewall. This does what we want but as its
a Microsoft Solution there might impose other requirements that our
customers might not want. Currently the simple Hybrid Connection Manager is free. But for how long?
Jscape MFT Gateway - Similar to Azure but you can host their server anywhere. Not that expensive but is not opensource.
Netty - A async java library/toolkit where this type of application could easily be build. Client and server apps would need to be build and deployed. Dont know what we dont know about Netty.
MDM, AirWatch, BlackBerry BES - A MDM based solution would work expect that MDM's are centrally managed and are not often in every office where the backend services are located. Airwatch has an AppTunnle but im not sure about the specifics.
At this point the Microsoft and Jscape systems are possible solutions.
But most likely these solutions will require us to modify the mobile software to work around issues such as:
How does the user know which server to login to? A locator service
needs to be built such that, an email address is used to lookup their
office, or they need to select their office location from a list.
While the connection is SSL many company might want some additional protection since network login information will be send down the pipe.
How is load balancing and fail-over managed?
So, at this point i'm looking for more options. The best option would be a commercial product that offers some level of customization. Second, would like a well used open-source product that could be installed in Aws and customized.
Thanks
The best approach we found was to use the PUTTY API and setup a reverse proxy.
We integrate with a third-party service where we can run queries which is right now secured using HTTPS encryption and username/password. We send our queries from a service running on the Windows Azure cloud.
The third-party provider wants to migrate towards better security and they have asked us to either
Setup a VPN - which is problematic because for we'd need to use Azure Connect and they'd have to install the client endpoint service on their part.
Provide some IP address where the queries will come from so they can filter out anyone else at the firewall level - which is problematic because AFAIK you cannot fix the IP addresses of the Windows Azure Compute nodes.
Suggest another secure alternative - the only thing I could think of is to set up the VPN with them on a non-Azure server and then tunnel the requests through using Azure Connect - which is obviously extra work for us and also defeats the point of hosting the service on a cloud if it depends on a non-cloud service.
Any ideas?
Can they install the Azure Connect endpoint on another server on their DMZ network? i.e. not the actual server which hosts their service?
Can we somehow provide them with static IPs for incoming queries?
Any other solution that is scalable?
Thanks
If I understand the scenario correctly, your Azure service is a client to a 3rd party service. This scenario may be solved through the use of the Windows Azure AppFabric Service Bus. You would need to install a proxy app in the 3rd party's datacenter that would be responsible for establishing the connection to the service bus. The connection comes from inside the 3rd party's datacenter, so no new incoming holes in the firewall. The connection can handle WCF connections with all its security strengths, and users can be authenticated with ACS.
Here is a starting point: http://msdn.microsoft.com/en-us/library/ee732537.aspx
There is a hands on lab in the Windows Azure Platform Training Kit that explains most of the details that you'll need.
IMHO, HTTPS is already very good; and I don't exactly see how a VPN would make the system any more secure. In particular, VPN is no silver bullet, if your VM is compromised then the VPN connection is compromised too (same for HTTPS). On the other hand, the IP restriction would indeed reduce the attack surface.
Then, using a server outside the cloud is a poor idea indeed. Not only it defeats most of the benefits of the cloud (been there, done that and suffered a lot), but also it also makes the whole thing less secure with more complexity and more attack surface.
Windows Azure does not provide anything that look like a static IP at this point. In our experience, IP addresses for a given service change once in a while even if the service is only upgraded (and never deleted). Static IP addresses have been an important feature request for a long time, Microsoft will probably provide it at some point, but it might still take many months.