{"id":79,"date":"2019-03-16T21:35:42","date_gmt":"2019-03-16T21:35:42","guid":{"rendered":"http:\/\/barry.phease.nz\/blog\/?p=79"},"modified":"2019-03-16T21:35:42","modified_gmt":"2019-03-16T21:35:42","slug":"security-networking-for-cloud-integration-sdp","status":"publish","type":"post","link":"http:\/\/barry.phease.nz\/blog\/?p=79","title":{"rendered":"Security & Networking for cloud integration \u2013 SDP"},"content":{"rendered":"\n

It is increasingly necessary to integrate applications across \nmultiple datacentres and cloud environments.  To further complicate \nmatters BYOD and home access need to be provided as well.  This problem \ntranscends integration, and a solution for integration can be extended \nto secure web apps and mobile device management.<\/p>\n\n\n\n

PaaS, SaaS and IaaS provide different secure networking solutions. \n  They all work well in the simple case where you have one *aaS solution\n connected to your secure network.  But these days people need to have \nmultiple solutions connected with any number of interconnections.<\/p>\n\n\n\n

An example I have to work with has integration provided in an AWS VPC\n which has a VPN connection into 2 datacentres, peering with another AWS\n VPC, a VPN to another SaaS provider and a VPN to another VPC in Azure. \n The IP addressing ran out in the VPC and it had to be moved to another \n(larger) IP range.  This meant duplicating all those VPNs.  Each VPN \nrequired engaging with a different network provider in turn and it took \nseveral months to finish the whole project.<\/p>\n\n\n\n

Adding DR doubles the number of connections required for each \nDatacentre duplicated.  So in the above situation a full DR solution \ncould require 25 VPNs.<\/p>\n\n\n\n

Each connection into a component in a datacentre requires a firewall \nrule to open up the port, and routing can get complicated.  It can be \nimproved by adding a gateway component in the datacentre.  The gateway \ncomponent handles all the traffic internal to the datacentre and can do \nsimple protocol conversion.  This simplifies routing and keeps all the \nconnection rules in one place.  The gateway component can be just as \nsecure as a firewall and is a lot more flexible.  The gateway component \ncan refuse non-SSL traffic and then it removes the need for VPNs.<\/p>\n\n\n\n

This gives a pointer to what a more comprehensive solution might look like.<\/p>\n\n\n\n

There are a number of rules that apply to cloud networking<\/p>\n\n\n\n

  1. TCP\/IP is flexible and scales well but provides poor security.<\/li>
  2. Any *aaS provided networking security option reduces flexibility to integrate with other providers.<\/li>
  3. VPNs do NOT scale.<\/li>
  4. Firewalls are very good at blocking agile delivery processes.<\/li>
  5. Any security solution needs to provide\/utilise Identity and Access Management.<\/li>
  6. One layer of (state of the art) encryption is sufficient for most purposes (no need for SSL across VPNs).<\/li>
  7. A solution that combines IAM with encryption and firewalls across \nthe internet gives the security of VPNs & firewalls without many of \nthe downsides.<\/li><\/ol>\n\n\n\n

    The answer is provided by some sort of Software Defined Perimeter \nsolution.  This is an emerging standard with some players providing good\n tools.  Access is managed by user or device, with all configuration in \none place (e.g. LDAP).  There is no need to manage devices separately \nfrom applications.<\/p>\n\n\n\n

    SDP uses identity to control network access.  A controller provides a\n grant token to a specific user.  The network denies access to clients \nwithout a valid and applicable token.  An existing network can be \nbrought into SDP with an SDP-aware gateway device.  Cloud providers \n(e.g. Azure) can offer SDP built into platform.<\/p>\n\n\n\n

    One advantage of SDP is you can have overlapping security zones and \nuse standard internet protocols to provide infinite flexibility and \nscale.  An individual component can incorporate its own SDP controller \nor an SDP controller can control access to all nodes within a secure \nnetwork segment.  An SDP controller can be part of several perimeters \nsimultaneously.<\/p>\n\n\n\n

    Single Sign On (SSO) can be baked into the solution for no extra \ncost.  The access token identifies the user and the same claims that \nprovide network access can also authorise individual services.  On the \nother hand legacy services with their own identity solutions will still \nwork in an SDP without using SSO.<\/p>\n\n\n\n

    It may be some time before enough *aaS providers provide compatible \nsolutions.  An SDP can be built from existing components, but an \nintegrated solution is easier to manage.<\/p>\n\n\n\n

    I haven\u2019t managed to implement this for any of my clients yet.  It is\n not just a question of putting in the infrastructure, but it is also a \nchange of mindset.  The network providers have to let go of the idea \nthat they can control security with firewalls and IP-based whitelists. \n Identity management becomes central to security as it should be.<\/p>\n\n\n\n

    Some links about SDP<\/p>\n\n\n\n

    https:\/\/en.wikipedia.org\/wiki\/Software_Defined_Perimeter<\/a><\/p>\n\n\n\n

    https:\/\/cloudsecurityalliance.org\/group\/software-defined-perimeter\/\/#_overview<\/a><\/p>\n\n\n\n

    A provider of SDP solutions for reference<\/p>\n\n\n\n

    https:\/\/www.cyxtera.com\/security-analytics\/appgate-sdp<\/a><\/p>\n\n\n\n

    \"sdp\"<\/figure>\n","protected":false},"excerpt":{"rendered":"

    It is increasingly necessary to integrate applications across multiple datacentres and cloud environments.  To further complicate matters BYOD and home access need to be provided as well.  This problem transcends integration, and a solution for integration can be extended to secure web apps and mobile device management. PaaS, SaaS and IaaS provide different secure networking … <\/p>\n

    Continue reading “Security & Networking for cloud integration \u2013 SDP”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[2],"_links":{"self":[{"href":"http:\/\/barry.phease.nz\/blog\/index.php?rest_route=\/wp\/v2\/posts\/79"}],"collection":[{"href":"http:\/\/barry.phease.nz\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/barry.phease.nz\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/barry.phease.nz\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/barry.phease.nz\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=79"}],"version-history":[{"count":1,"href":"http:\/\/barry.phease.nz\/blog\/index.php?rest_route=\/wp\/v2\/posts\/79\/revisions"}],"predecessor-version":[{"id":80,"href":"http:\/\/barry.phease.nz\/blog\/index.php?rest_route=\/wp\/v2\/posts\/79\/revisions\/80"}],"wp:attachment":[{"href":"http:\/\/barry.phease.nz\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=79"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/barry.phease.nz\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=79"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/barry.phease.nz\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=79"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}