Secured Approach to Cloud Telephony Services

A Secured Approach to Cloud Telephony Services

Secured Approach to Cloud Telephony Services

Image credit: Flickr user opensourceway

One of the common dilemmas to most “mission critical” cloud service providers is whether an on-premise border gateway or tool should be part of their architecture for connecting on-premise software and HW appliances to their cloud services.

The purposes of such a border gateway or tool are various and depend on the cloud services provided. For example, a familiar tool is the AWS Storage Gateway. This gateway connects on-premise appliances to the Amazon Cloud storage services. Other cloud services such as big data analytics and network performance monitoring architecture may include on-premise tools for remote sniffing, data gathering, filtering, transforming, preliminary analysis and mass data transport.

When thinking of using a cloud service for enterprise telephony, a common decision point is whether to connect the enterprise IP Phones directly to the telephony service provider or to deploy an on-premise cloud appliance.

Actually, an enterprise cloud-based VoIP services architecture, dictates the need for an on-premise Session Border Controller for basic operation solving connectivity, (i.e. NAT traversal), security, resilience and quality issues.

Connecting the enterprise to the service provider cloud through VPN

Trying to reduce costs, VoIP service providers often bypass connectivity and security issues by connecting the Enterprise to the cloud using VPN over IPsec or MPLS-VPN service with or without standard End-to-End Service Level Agreements and performance reporting.

Both VPN-IPsec and VPN-MLPS connections simulate a L2/L3 LAN with the service provider. This architecture obviates the need for NAT traversal and on-premise VoIP security, as VoIP clients and IP phones share the same IP subnet with the service provider SBC.

Enterprise-Cloud-Over-VPN

VPN connection between the enterprise and the service provider

Adding Multitenancy

This approach may be satisfying for private or dedicated cloud architectures, although it doesn’t provide a solution for resiliency and voice quality monitoring. However, for cloud-based VoIP service providers who provide service to multiple enterprises, this approach is problematic.

Multi-tenant-SBC

Multiple tenants connected to the service provider through VPN

Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server or HW system, serving multiple client-organizations. Although multitenancy can be achieved by running multiple instances of the application, in most cases multi-tenancy is designed by virtually partitioning an SBC data and configuration. Each tenant works with a segregated non-bleeding virtual application instance.

Multi-tenant cloud-based VoIP services share a single application server instance (i.e. IP PBX, application servers) and network entities instance (i.e. access SBC, peering SBC) between several tenants.

Seemingly, multi-tenant shouldn’t present any security or other issue, but in reality, this tenant segregation is almost impossible since, after all, tenants may share network interfaces (same IP and port 5060), and a SIP trunk or MGW in the northbound, so the segregation is not complete. An attack on one of the tenants or a misconfiguration of one of the shared resources, compromises all of the tenants’ security. In such a case,  as the tenants are sharing the same L2/L3 with the service provider and relying on the service provider IDS (intrusion detection server) and IPS (intrusion prevention server), a simple intrusion can be destructive.

Cloud-Appliance

 An SBC as demarcation point between the enterprise and the service provider

Isolating the enterprise from other tenants’ security threats

Organizations that can’t afford compromising their security and can’t trust 3rd party security services, should deploy an enterprise SBC as a demarcation point.

An Enterprise SBC provides:

  • Support for back-to-back user agent (B2BUA) functionality
  • Security and privacy (personal information is not forwarded to the cloud)
  • Emergency calls and regulatory
  • Resiliency
  • Remote Agent termination
  • Registration throttling
  • Voice Quality Monitoring
  • Call Admission Control and Rate Limiting.
  • Registrations overload and avalanche protection
  • On-premise recording, the SBC forks the calls

Finally, cloud-based VoIP services can be connected to an Enterprise via VPN-IPsec or VPN-MLPS without the need for an Enterprise SBC. However in choosing this path, the enterprise loses much of the above mentioned functionality related to the SBC and puts the enterprise in a security risk as well.

2 replies
  1. Paul says:

    Very well put. This information is not usually provided to the clients and hence a lot of them don’t know what they are missing out or what they are exposing themselves to.

    Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

Captcha *