WHITEPAPER SECURITY APPROACHES AND SECURITY TECHNOLOGIES IN INTEGRATION CLOUD

Transcription

1 WHITEPAPER SECURITY APPROACHES AND SECURITY TECHNOLOGIES IN INTEGRATION CLOUD

2 TABLE OF CONTENTS 1 In this whitepaper User security Authentication Authorization & Access Control Data security Types of data stored Data isolation Data location Duration of data storage Data security External communication Web service security Cloud connector security Virtual networking capabilities Database security Conclusion More information?... 9 Last Update: September 2015 All Rights Reserved 2 10

3 1 IN THIS WHITEPAPER When working with an online platform, security is a key concern to many enterprises. In this document, you will find an overview of the different security approaches and technologies used on Integration Cloud, the online integration platform. Integration Cloud is an online integration platform that enables you to connect your applications and business partners in a reliable and transparent cloud environment. The platform helps you set up connections and integrations quickly and most efficiently and requires no investments in hardware, licenses and installations upfront. It enables you to start your integration in a matter of hours. Integration Cloud allows you to set up a hybrid integration infrastructure and securely connect to your applications, data or existing middleware through the internet. Built on Microsoft Azure technology, the online platform fully leverages the benefits and capabilities of Microsoft Azure and cloud technology. Built by integration experts, it brings you years of integration experience "as a service", at your immediate disposal. In any scenario Integration Cloud provides you with a business-oriented and user-friendly platform: Business-to-business Distributed Enterprise Application Integration (EAI) Exposing local data Elastic integrations This whitepaper aims to describe the different security approaches and security technologies that are being used on Integration Cloud. Last Update: September 2015 All Rights Reserved 3 10

4 2 USER SECURITY 2.1 AUTHENTICATION There are 2 types of authentication Username / password authentication This is the default and lightweight approach, used by most customers. Here, a user can log on with a username and a password that is maintained by our platform. Because of using standard frameworks for this, we use best practices such as hashing / salting of passwords Active directory authentication Another way of logging on to our portal, is through Active Directory credentials. Here are the options: Connecting, using an existing on premise Active Directory It is possible for users to log on, using their local Active Directory credentials. This is possible by setting up Active Directory Federation Services and have our platform trusting the Security Token Service (STS) of Active Directory. Still the actual authorization policies are defined on our platform, as they are very granular Connecting, using a Microsoft Azure Active Directory logon Microsoft Azure also provides an Active Directory (for example used by Office 365). It is possible to connect to our portal using these credentials. This setup requires less configuration and is easier to achieve. Another option is Two-Factor Authentication, which provides even better security, as a user has to confirm his identity through a text-message, or by answering an automated phone call Using other authentication providers Our portal is ready for other federated types of logins, using third party providers (such as Google, Facebook, Microsoft Account, etc ). 2.2 AUTHORIZATION & ACCESS CONTROL Once a user is logged on to the system, the authorization comes into play. We have a granular set of Access Rules. Last Update: September 2015 All Rights Reserved 4 10

5 2.2.1 User roles First of all, a user can get assigned a specific role per module in the application, as seen in the screenshot. There are 5 different modules, to which a user can get assigned an Administrator, a regular User or a Read-Only user: Configuration: in the configuration module, all settings can be seen and configured e.g. how to connect to other systems, what workflows are being used,... Monitoring: in the monitoring module, users can get an overview of all the different endpoints and services on the platform. Based on their role for this module, users can stop/start endpoints or just see the status of the endpoints. Deployment: in the deployment module, users can change the behavior of the processes. Code components, transformations and workflows can be uploaded, if users have the required access rights. Edoc: this is where Trading Partner management happens and where users can see all the exchanged electronic documents, the different trading partners and the agreements. Tracking: the tracking module shows the history of all processes, where users can search for specific messages, see what happened with them and even handle (e.g. resume) the messages if they have the required role assigned Artifact specific user rights In every environment, a user has access to, can be defined to which artifacts he has access. Business activities: we can assign a user to one or more business activities. These are the different processes or containers in which messages are processed isolated. (There can be an activity for Invoicing, for Dispatch Advices and one for Human Resources, for example.) Transco databases: a user can get access to a specific Transco database (schema). In this database schema, a user can change data of the tables. This is typically done for data lookups at runtime (translation of articles, EAN codes, etc). Reports: for every environment, multiple reports can be defined. It is possible to only make reports available to a set of users. These reports are visualized on the home page of the user s portal. edoc types: here can be defined that a certain user can only see a certain type of electronic documents. These document types are visible in the edoc module (for example: only outgoing invoices). Cloud connectors: the cloud connector is an on premises installation that we use to connect to local systems. A certain user can only have access to manage a specific cloud connector. Last Update: September 2015 All Rights Reserved 5 10

6 3 DATA SECURITY 3.1 TYPES OF DATA STORED In our platform, 3 types of data are stored Configuration & Tracking data Configuration data is the data that is defining the behavior and configuration of our platform. This contains data such as server settings, intervals, URL s,... We also store the tracked events and metadata of the different messages and processes we execute on our platform. We use these to show the replay of the messages, to search for historical data, or we can even build reports. All of this data is stored in Microsoft Azure databases (SQL Azure) Archived message bodies To be able to resume, download or resubmit messages, if need be, message bodies are stored in the cloud. These messages are stored in Microsoft Azure blob storage In flight message events Because of the asynchronous nature of cloud integration, we also store messages temporarily in queues. As soon as a message is processed, the message is removed from the queue. Having a queuing mechanism allows us to build a robust and scalable platform. These messages are stored in Microsoft Azure Service Bus queues. 3.2 DATA ISOLATION Every environment (customer/tenant) has its dedicated storage containers: - A dedicated Microsoft Azure SQL database - A dedicated Microsoft Azure storage account - A dedicated Microsoft Azure Service Bus namespace If a customer has two environments (Test / Prod), these will also have their own storage container. We chose this design for two important reasons: - Data security and isolation - Flexibility to scale and move data between data centers Last Update: September 2015 All Rights Reserved 6 10

7 3.3 DATA LOCATION Choice of data location As we are building on Microsoft Azure and all of our data is stored in Microsoft Azure, we can decide in which location our data will be stored. For that, we can chose between different data centers. Each year, new data centers are being added to Microsoft Azure, so there might be more data centers at the moment you are reading this paper, than the ones described in this document. The most important thing to remember is that we can define and even change data to reside in one of the data centers available. The latest list of data center locations can be found here: Geo replication of data Microsoft Azure storage is geo-replicated by default, but this can be turned off if wanted. The location where we read, create, update, or delete data is referred to as the primary location. The primary location is in the region we chose at the time of the Azure storage account creation. The location where the data is geo-replicated is referred to as the secondary location. The secondary location is automatically determined based on the location of the primary; it is in the other data center that is in the same region as the primary. The table shows the primary and secondary location pairings. Primary North Central US South Central US East US West US North Europe West Europe South East Asia East Asia Secondary South Central US North Central US West US East US West Europe North Europe East Asia South East Asia 3.4 DURATION OF DATA STORAGE In Integration Cloud, we have built-in purge procedures, where we can specify the duration of how long data should reside in the cloud. We can configure this per business activity, so that legal e-invoices don t get purged, where daily stock movements could get purged after 7 days, for example. 3.5 DATA SECURITY For data privacy, reliability and security, we rely on the Microsoft Azure platform and the robust security that is offered by this platform. You can find a detailed description in the Microsoft Azure trust center: The data centers of Microsoft Azure comply with industry standards, such as ISO/IEC 27001:2005, for security and reliability. We strongly advise to have a look at the above mentioned trust center, where you will find more information about security described in detail. Last Update: September 2015 All Rights Reserved 7 10

8 4 EXTERNAL COMMUNICATION A cloud integration platform also has to connect to other systems and platforms. And also here, we use security best practices to achieve a secure and reliable connection. 4.1 WEB SERVICE SECURITY When we expose an endpoint over a web service, so that other applications can send to this endpoint, we leverage Windows Identity Foundation to secure these connections. Based on the capabilities of the client application, we can chose and combine amongst the following options to make the connection: Certificate based authentication & authorization Message security (messages are signed and/or encrypted on the wire) Transport security (sending messages over HTTPS/SSL) SAML/oAuth IP Address restrictions / ACL 4.2 CLOUD CONNECTOR SECURITY When integrating to local systems (databases, file system, web services ) that are not connected over a virtual network with our cloud runtime, we use the Cloud Connector. This is a lightweight local installation that can connect to local systems, using a set of (pluggable) adapters. Data can be read from systems and sent to Integration Cloud. Or Integration Cloud can send data to the cloud connector that, in turn, will submit the data to the local system. In both connections, we use the same techniques as mentioned above (in web services). Or we can also combine it with the Service Bus Relay capabilities, which are firewall friendly. 4.3 VIRTUAL NETWORKING CAPABILITIES It is possible to connect Integration Cloud in a virtual network with other servers (either locally or in the cloud). This can be achieved through Microsoft Azure Virtual Networking: we can leverage this Virtual Network to set up an VPN in order to get a secure tunnel (using IPSEC as security protocol). This allows us to directly call or be called by other servers in the same network. 4.4 DATABASE SECURITY Microsoft Azure SQL Database provides a relational database service for Microsoft Azure and other Internet-based applications. The SQL Database firewall prevents all access to your SQL Database server until you specify which computers have permission. The firewall grants access based on the originating IP address of each request. Last Update: September 2015 All Rights Reserved 8 10

9 5 CONCLUSION For Integration Cloud, we build on the Microsoft Azure platform that is secure by design. Moreover, we apply all security best practices and take extra caution when connecting to external systems, outside of the Microsoft Azure network. With Integration Cloud, we take security, privacy and reliability as a fundamental requirement for development and design. 6 MORE INFORMATION? For more information or a demo of Integration Cloud, contact us via [email protected] W: B: Skaldenstraat 7b, BE-9042 Gent, Belgium T F , rue de l Escaut, FR Paris, France T F Praça Duque de Saldanha, nº 20-1ºD, P Lisboa, Portugal T /4 F Codit Skaldenstraat 7b, BE-9042 Gent, Belgium T F , rue de l Escaut, FR Paris, France T F Praça Duque de Saldanha, nº 20-1ºD, P Lisboa, Portugal T /4 F

10 ABOUT CODIT Large, international companies often struggle to easily exchange data with their subsidiaries, customers, suppliers and other business partners. Many also face challenges with the upcoming trends such as Cloud, SaaS apps, Mobile, Internet of Things, Big Data Companies not only have to be aware of them, yet have to adopt these technology changes strategically to gain competitive advantage. That is exactly what our expert teams do: we integrate business applications with the newest Microsoft technologies. Codit is a leading IT services company providing consultancy, technology and managed services in business integration. We successfully help companies reduce operational costs, improve efficiency and enhance control by enabling people and applications to integrate more efficiently. Having started as a highly competent Microsoft BizTalk Server specialist, we have grown substantially to become a leader in business integration using a wide range of Microsoft technologies, including cloud-based solutions such as Microsoft Azure. ABOUT THE AUTHORS Wouter Seye Wouter Seye is Lead Product Developer with Codit. He has over 12 years of experience in developing on the.net platform and has been working with Microsoft Azure since the early bits. As such, Wouter has helped developing and designing the online integration platform Integration Cloud. By nature he has a keen interest in development best practices and patterns. Sam Vanhoutte Sam Vanhoutte is CTO and Product Manager with Codit and is a Microsoft Integration MVP. He is also BizTalk Virtual Technology Specialist and has extensive experience in building integrated enterprise, ESB and SOA solutions. Because of the specialized focus on integration on Microsoft technology, Sam is part of Microsoft's Connected Systems and Azure Advisory boards and is an Azure Insider as well as a Belgian MEET member. Sam co-founded the BizTalk User Group in Belgium ( and is an active crew member of the Azure User group ( While managing and architecting the online integration platform "Integration Cloud," Sam has been focusing on Cloud integration with the Microsoft Azure platform the last years, focusing on the Azure Service Bus and BizTalk Services technology. Sam is blogger on the Codit blog and tweets via DISCLAIMER This document, any attachments and the information contained therein (together the Document ) are confidential and to be considered as Confidential Information within the meaning of any agreement between Codit and the recipient. The Document is intended solely to be used by the addressee(s) for whom Codit meant it. If you have received the Document in error please send it back to the sender and delete it. The recipient of the Document is not allowed to make any use of -or to perform any act regarding the Document which is not explicitly permitted by Codit. Unauthorized use, dissemination or disclosure of the Document, either in whole or in part is strictly prohibited. Last Update: September 2015 All Rights Reserved 10 10