Merge pull request #39 from DonMartin76/master
Made the links in my latest blog post a little less raw-looking.
This commit is contained in:
commit
8cc1cba092
|
@ -39,7 +39,17 @@ layout: default
|
||||||
{% endif %}
|
{% endif %}
|
||||||
{% endif %}
|
{% endif %}
|
||||||
-->
|
-->
|
||||||
|
{% if post.author %}
|
||||||
|
{% assign author = site.data.authors[post.author] %}
|
||||||
|
{% if author %}
|
||||||
|
{% assign author_name = author.name %}
|
||||||
|
{% else %}
|
||||||
|
{% assign author_name = post.author %}
|
||||||
|
{% endif %}
|
||||||
|
{% else %}
|
||||||
|
{% assign author_name = site.title %}
|
||||||
|
{% endif %}
|
||||||
|
|
||||||
<div class="post-preview">
|
<div class="post-preview">
|
||||||
<a href="{{ post.url | prepend: site.baseurl }}">
|
<a href="{{ post.url | prepend: site.baseurl }}">
|
||||||
<h2 class="post-title"> {{ post.title }}
|
<h2 class="post-title"> {{ post.title }}
|
||||||
|
@ -50,7 +60,7 @@ layout: default
|
||||||
</h3>
|
</h3>
|
||||||
{% endif %}
|
{% endif %}
|
||||||
</a>
|
</a>
|
||||||
<p class="post-meta">Posted by {% if post.author %}{{ post.author }}{% else %}{{ site.title }}{% endif %} on {{ post.date | date: "%B %-d, %Y" }}</p>
|
<p class="post-meta">Posted by {{ author_name }} on {{ post.date | date: "%B %-d, %Y" }}</p>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<hr>
|
<hr>
|
||||||
|
|
|
@ -39,7 +39,17 @@ layout: default
|
||||||
{% endif %}
|
{% endif %}
|
||||||
{% endif %}
|
{% endif %}
|
||||||
-->
|
-->
|
||||||
|
{% if post.author %}
|
||||||
|
{% assign author = site.data.authors[post.author] %}
|
||||||
|
{% if author %}
|
||||||
|
{% assign author_name = author.name %}
|
||||||
|
{% else %}
|
||||||
|
{% assign author_name = post.author %}
|
||||||
|
{% endif %}
|
||||||
|
{% else %}
|
||||||
|
{% assign author_name = site.title %}
|
||||||
|
{% endif %}
|
||||||
|
|
||||||
<div class="post-preview">
|
<div class="post-preview">
|
||||||
<a href="{{ post.url | prepend: site.baseurl }}">
|
<a href="{{ post.url | prepend: site.baseurl }}">
|
||||||
<h2 class="post-title"> {{ post.title }}
|
<h2 class="post-title"> {{ post.title }}
|
||||||
|
@ -50,7 +60,7 @@ layout: default
|
||||||
</h3>
|
</h3>
|
||||||
{% endif %}
|
{% endif %}
|
||||||
</a>
|
</a>
|
||||||
<p class="post-meta">Posted by {% if post.author %}{{ post.author }}{% else %}{{ site.title }}{% endif %} on {{ post.date | date: "%B %-d, %Y" }}</p>
|
<p class="post-meta">Posted by {{ author_name }} on {{ post.date | date: "%B %-d, %Y" }}</p>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<hr>
|
<hr>
|
||||||
|
|
|
@ -58,11 +58,11 @@ Checking the certificate in the backend can be simple or challenging, depending
|
||||||
|
|
||||||
* nginx: See above link to the tutorial on how to verify the client certificate; SSL termination with nginx is probably quite a good idea
|
* nginx: See above link to the tutorial on how to verify the client certificate; SSL termination with nginx is probably quite a good idea
|
||||||
* Apache web server also directly supports Client Certificate verification
|
* Apache web server also directly supports Client Certificate verification
|
||||||
* Spring Boot: Intended way of securing the service, see e.g. [http://docs.spring.io/spring-security/site/docs/4.0.4.CI-SNAPSHOT/reference/htmlsingle/#x509](http://docs.spring.io/spring-security/site/docs/4.0.4.CI-SNAPSHOT/reference/htmlsingle/#x509)
|
* Spring Boot: Intended way of securing the service, see e.g. [Spring Boot Security Reference (v4.0.4)](http://docs.spring.io/spring-security/site/docs/4.0.4.CI-SNAPSHOT/reference/htmlsingle/#x509).
|
||||||
* Web API/.NET: Funnily, in the case of .NET applications, verifying a client certificate is quite challenging. There are various tutorials on how to do this, but unfortunately I don't like any of them particularly:
|
* Web API/.NET: Funnily, in the case of .NET applications, verifying a client certificate is quite challenging. There are various tutorials on how to do this, but unfortunately I don't like any of them particularly:
|
||||||
* [http://chimera.labs.oreilly.com/books/1234000001708/ch15.html#example_ch15_cert_handler](http://chimera.labs.oreilly.com/books/1234000001708/ch15.html#example_ch15_cert_handler)
|
* [Suggestion from 'Designing evolvable Web APIs using ASP.NET'](http://chimera.labs.oreilly.com/books/1234000001708/ch15.html#example_ch15_cert_handler)
|
||||||
* [https://azure.microsoft.com/en-us/documentation/articles/api-management-howto-mutual-certificates/](https://azure.microsoft.com/en-us/documentation/articles/api-management-howto-mutual-certificates/)
|
* [How to use mutual certificates with Azure API Management](https://azure.microsoft.com/en-us/documentation/articles/api-management-howto-mutual-certificates/)
|
||||||
* [https://azure.microsoft.com/en-us/documentation/articles/app-service-web-configure-tls-mutual-auth/](https://azure.microsoft.com/en-us/documentation/articles/app-service-web-configure-tls-mutual-auth/)
|
* [Azure App Services - How to configure TLS Mutual Authentication](https://azure.microsoft.com/en-us/documentation/articles/app-service-web-configure-tls-mutual-auth/)
|
||||||
* For node.js and similiar, I would suggest using nginx for SSL termination (as a reverse proxy in front of node)
|
* For node.js and similiar, I would suggest using nginx for SSL termination (as a reverse proxy in front of node)
|
||||||
|
|
||||||
All in all, using mutual SSL is a valid approach to securing your backend; it offers real security. It will still be possible to flood the network interface with requests (which will be rejected immediately due to the SSL certificate mismatch), and thus could and possibly should be combined with the below method additionally.
|
All in all, using mutual SSL is a valid approach to securing your backend; it offers real security. It will still be possible to flood the network interface with requests (which will be rejected immediately due to the SSL certificate mismatch), and thus could and possibly should be combined with the below method additionally.
|
||||||
|
@ -74,7 +74,7 @@ I am waiting for simpler solutions of doing this directly in Azure, but currentl
|
||||||
In case your backend service runs in an Azure VM (deployed using ARM, Azure Resource Manager), you can make use of the built in firewall, the Network Security Groups. As of the Standard Tier (which is the "cheapest" one you are allowed to use in production), your Azure APIm instance will get a static IP; this IP in turn you can use to define a NSG rule to only allow traffic from that specific IP address (the APIm Gateway) to go through the NSG. All other traffic will be silently discarded.
|
In case your backend service runs in an Azure VM (deployed using ARM, Azure Resource Manager), you can make use of the built in firewall, the Network Security Groups. As of the Standard Tier (which is the "cheapest" one you are allowed to use in production), your Azure APIm instance will get a static IP; this IP in turn you can use to define a NSG rule to only allow traffic from that specific IP address (the APIm Gateway) to go through the NSG. All other traffic will be silently discarded.
|
||||||
|
|
||||||
As mentioned above, it's unfortunately not (yet) possible to add an Azure APIm instance to a virtual network (and thus put it inside an ARM NSG), but you can still restrict traffic into the NSG by doing IP address filtering.
|
As mentioned above, it's unfortunately not (yet) possible to add an Azure APIm instance to a virtual network (and thus put it inside an ARM NSG), but you can still restrict traffic into the NSG by doing IP address filtering.
|
||||||
The following whitepaper suggests that Azure virtual networks are additionally safeguarded against IP spoofing: [http://download.microsoft.com/download/4/3/9/43902ec9-410e-4875-8800-0788be146a3d/windows%20azure%20network%20security%20whitepaper%20-%20final.docx](http://download.microsoft.com/download/4/3/9/43902ec9-410e-4875-8800-0788be146a3d/windows%20azure%20network%20security%20whitepaper%20-%20final.docx)
|
The following whitepaper suggests that Azure virtual networks are additionally safeguarded against IP spoofing: [Azure Network Security Whitepaper](http://download.microsoft.com/download/4/3/9/43902ec9-410e-4875-8800-0788be146a3d/windows%20azure%20network%20security%20whitepaper%20-%20final.docx).
|
||||||
|
|
||||||
This means that if you create an NSG rule which only allows the APIm gateway to enter the virtual network, most attack vectors are already eliminated by the firewall: Azure filters out IP spoofed packages coming from outside Azure when they enter the Azure network, and additionally they will inspect packages from inside Azure to validate they actually origin from the IP address they claim to do. Combined with Mutual SSL, this should render sufficient backend service protection,
|
This means that if you create an NSG rule which only allows the APIm gateway to enter the virtual network, most attack vectors are already eliminated by the firewall: Azure filters out IP spoofed packages coming from outside Azure when they enter the Azure network, and additionally they will inspect packages from inside Azure to validate they actually origin from the IP address they claim to do. Combined with Mutual SSL, this should render sufficient backend service protection,
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue