For those who have not yet taken the plunge (mainly ETIs and the public sector), it is essential to start thinking about Cloud collaboration and communication platforms as soon as possible. This, in order to be able to ensure continuity of service in case of force majeure (cyber attack, natural disaster or even pandemic), or even to envisage a more consequent migration.

For this Digital Workplace platform, a close collaboration between the security team and the workplace will be a prerequisite!

In this article, I will share with you some feedbacks on the deployment of Office 365, Microsoft’s solution that is becoming increasingly popular with the companies we support.

There is a lot of interesting documentation on the subject on the Internet (“Top 10 best practices” or “3 good reasons to connect the xxx application to ensure your security”). Microsoft summarizes some of these good practices in these two articles:

• Security roadmap – Top priorities for the first 30 days, 90 days, and beyond
• Top 10 ways to secure Microsoft 365 for business plans

Today, I am not going to repeat here a non-exhaustive list of these good practices, but rather to remind you of six points of attention when opening such a service.

1st point: Building the safety standard, a pillar of the future relationship between the safety and workplace teams.

As with any project of this type, the first step is to assess the potential of the service and see how it can meet the initial need, through the development of a business case. The possibilities offered by Office 365 are numerous: office automation, instant messaging or email, data visualization, development of applications without code, etc.

As far as cybersecurity teams are concerned, there are two choices: to oppose this migration because of the risks linked to the American Cloud or to support the reflection to create new secure uses.

In the vast majority of cases, the second choice is preferred. A tripartite relationship then begins, between the workplace teams, security and architects, with the aim of building a service for the users. A result of this step could be the development of a security standard, resulting from a risk analysis, defining the services used and with the associated configuration.

Among the issues to be addressed are generally the following three themes:

• What uses should be offered to people in a situation of mobility? With what authentication?
• What new services to offer with the possibilities of integration with APIs?
• How to share documents with external users?

The current trend is to provide answers with a “Zero Trust” approach. Any deviation from the defined safety standard will have to be detected, thanks to the implementation of dashboards and supervision. The adage “Trust does not exclude control” has never made more sense.

This reflection may even be an opportunity to ask fundamental questions in order to lay a coherent foundation for the working environment. For example, why leave email, a 30-year-old system, open to everything and externally block my Teams and SharePoint shares? Improving the user experience can only be achieved by standardizing security practices.

2nd point: Data protection, a subject with the wind in its sails

Parallel to the construction of the service, comes the subject of the data that will be used in the tenant. For this, two simple questions must find answers (often complex).

How do I protect my data?

Today, unstructured data protection strategies are based on a common basis: the linking of data to a level of sensitivity. This correspondence leads to protection measures to be put in place:

• – Encryption with keys controlled by the CSP or the organisation;
• – Restriction of rights (or DRM);
• – Conditional access with multi-factor authentication;
• – Data Leakage Protection (or DLP).

In order not to over-protect data and thus avoid undermining the user experience, encryption and rights restriction can be reserved for the most critical data. Other data will still remain under control using more traditional measures, such as end-to-end encryption and exposure control.

A key factor for such a project will be to turn it into a real business project, with a comprehensive awareness programme dedicated to classification.

How to remain compliant with the regulations?

An organisation may be subject to local, implementation-related and sector-specific regulations, depending on its activities.

These regulations and directives in some cases impose real obstacles that need to be removed at the outset of the project: data retention, legal archiving, geolocation, judicial investigation, requests related to personal data.

Let’s take a concrete example: Russia. With the law on personal data of 2015, the national regulatory authority imposes the obligation to keep the source (called primary database) of its citizens’ data on Russian soil. In practice, this means that the Active Directory (primary base of corporate identities) of the Russian entity must remain Russian. From there, the information can be synchronized with the GAL (Global Access List) and Azure Active Directory.

The thorny issue of stock management

What to do with the data already existing? This is a complex issue, especially if the opening of a Cloud collaboration solution is linked to the decommissioning of existing file servers.

First of all, there is a technical question. Will the company’s network be able to support massive migrations of .pst and documents? In particular, it will not necessarily be useful to migrate data that does not comply with the retention policy.

Secondly, historical data may have heterogeneous levels of sensitivity and be subject to various regulations. A trade-off will be necessary to arbitrate between local data retention, risk acceptance and a broad classification project before or after migration.

3rd point: The Target Operating Model, guaranteeing the preservation of security over time

The operational model of a service such as Office 365 defines the responsibilities of the players (administrators, support staff, etc.) and the principles of object management. It is complementary to the security standard mentioned above, providing an operational vision.

The TOM must be drawn up prior to the opening of the service and updated regularly. It must include at least the following subjects.

A model of administration

Microsoft offers by default about 50 administration roles, not counting the RBAC roles of services (e.g. Exchange and Intune). A relevant use of these roles and custom roles will help to avoid having too many General Administrators and to follow the principle of least privilege. The implementation of Just-in-Time access will moreover make it possible to monitor the actual use of roles, while reinforcing security.

A semi-architectural / semi-security community

Like any SaaS platform, Microsoft regularly upgrades the functionalities of its collaborative suite. The mission of this community will be to monitor trends, in order to master new uses and keep control of the tenant considering the evolutions.

The life cycle of shared identities and spaces

If shared spaces (Teams, SharePoint) are not managed freely, this can lead to an explosion in the number of spaces that do not comply with the security standard. The reports of the editors of Data Discovery solutions are quite striking. To avoid this, it is necessary to establish a life cycle for shared spaces. These rules can include a naming convention, retention policies, a lifespan, principles for rights management.

The establishment of a single portal for the creation of these spaces will make it possible to implement these good practices, while promoting the user experience.

Similarly, a life cycle for Azure AD objects (including guest users, security groups, Office 365 groups and applications) must be defined and equipped. Here are two examples that deserve to be addressed: the delegation of APIs is left open and leaves the door open to massive data leaks; users invited to collaborate are never deleted. For this, two strategies are possible:

If shared spaces (Teams, SharePoint) are not managed freely, this can lead to an explosion in the number of spaces that do not comply with the security standard. The reports of the editors of Data Discovery solutions are quite striking. To avoid this, it is necessary to establish a life cycle for shared spaces. These rules can include a naming convention, retention policies, a lifespan, principles for rights management.

The establishment of a single portal for the creation of these spaces will make it possible to implement these good practices, while promoting the user experience.

Similarly, a life cycle for Azure AD objects (including guest users, security groups, Office 365 groups and applications) must be defined and equipped. Here are two examples that deserve to be addressed: the delegation of APIs is left open and leaves the door open to massive data leaks; users invited to collaborate are never deleted. For this, two strategies are possible:

• #1 – Creation of a Custom Automation Engine decorrelated from the IAM, via an in-house application developed in PowerShell ;
• #2 – Integration of a Powershell / Graph API connector to the IAM solution in place in order to present a complete management of the objects, disregarding their direct hosting.

4th point: take a fresh look at the subject of user identity

Indeed, the subject of identity is a pillar of SaaS!  So, take the time to consider all the possibilities and risks of SaaS Identity Providers (or IdPs). In particular, it is unthinkable in 2020 to consider Azure Active Directory as a simple Domain Controller in the Cloud.

Three approaches are possible for the source of identities accessing Office 365.

The dissociation of identities, a quick-win but complicated from a user’s point of view

It is possible to dissociate the local and Cloud identities if the local DA is no longer available or to decorate the Cloud workspace from the historical IS. This scenario is obviously not in favour of an optimal experience, but may be a valuable asset in the event of a crisis.

The use of local identity in the Cloud, a classic strategy

In order to reconcile security and user experience, it is necessary to use the same identity between the legacy applications and this new service. For this, three technical scenarios are available:

• Identity Federation : This historic solution is widely used by large French companies that are reluctant to host passwords in the Cloud and wish to have SSO;
• Password Hash Sync (PHS): This solution, recommended by Microsoft and the British equivalent of ANSSI, is implemented by the vast majority of Microsoft customers. This solution can also be used as a back-up when the federation service is no longer available;
• Direct Authentication (Password Through Authentication or PTA): This solution provides the best user experience but has the disadvantage of passing the password through Azure AD.

Migrating one’s identity repository to the Cloud, a longer-term vision

Before or after migration, it may be appropriate to consider fully migrating the source of identities into the Cloud (whether Azure AD or a third party solution), in order to take advantage of the new possibilities. There are still several prerequisites that need to be lifted, such as printer, GPO and terminal management.

5th point: Gradually open up services to encourage controlled adoption

It is always easier to open a new service than to go back for safety reasons. Massively opening the different services of the collaborative suite has the advantage of offering a maximum number of uses cases but can cause several side effects.

First of all, services that are not officially supported and left in the hands of users for testing purposes represent a definite risk. They need to be configured and hardened. In some cases, it may even be preferable to disable the corresponding licenses.

Secondly, a controlled launch of the tools will help control costs during the first months or years of the transition. As Microsoft licences represent a certain load, it is possible to optimize unused licences.

Change management is also a key aspect to consider; to promote the user experience, of course, but also to promote data security. It is essential to have a clearly defined roadmap and user journey. Accompanied adoption will lay the foundations for proper governance of shared spaces and data (both in terms of exposure and protection).

It will be useful to consider creating a community of evangelists and users in order to maintain momentum in the adoption of the new functionalities brought by Microsoft. A uservoice system could be an asset; the ideal would be to listen to the needs of users and prioritise future openings.

6th and last point: Licences, the lifeblood of Office 365 and its security

SaaS solutions are generally subject to a monthly invoiced licensing model. The choice of Microsoft 365 licences must be the result of a global reflection. It cannot remain the prerogative of workplace teams and be determined solely by the need for collaboration and communication.

Indeed, the choice of licensing level will condition the security strategy of the tenant. This choice will have a wider impact on the strategy for securing the work environment. Indeed, Microsoft is increasingly positioning itself as a challenger to security solution providers, being the only one to offer such a complete suite.

The licensing of security options must be dealt with at the start of the project and at each renewal. It will be cheaper to include a licensing package from the outset than to order AAD P1 licences on an emergency basis to cover an unforeseen need for conditional access.

In this strategy to be defined, it may be appropriate to target individuals to adapt the security requirements to their profile (VIP, admin, medical population, etc.).

This approach, presented here for Office 365, can be generalised to any SaaS (Solution as a Service) service, or even IaaS (Infrastructure as a Service) or PaaS (Platform as a Service) service.

Cet article Migrate your work environment to Office 365 with confidence est apparu en premier sur RiskInsight.

SAAS COMPUTER BACKUP: THE SERVICE PROVIDER’S RESPONSIBILITY TO PUT IN PLACE

SaaS (Software as a Service) is software that is made available on, and consumed directly from, the internet. It is managed by one or more providers.  The customer does not have the wherewithal to carry out the backup activities is case of disaster (no access to raw data, source codes, applications that could duplicate the infrastructure, etc.), so it has to rely on the provider’s goodwill.

Levels of disaster recovery are variable for SaaS, depending on the provider’s degree of maturity

Three major trends are emerging:

• Providers who offer an inclusive disaster recovery plan. As part of their standard offering, the provider offers recovery at a remote data center, usually augmented with outsourced backup. However, they rarely offer commitments on recovery times.
  Examples are the big SaaS players (such as: Office 365, SalesForce, and SAP), as well as some intermediate players (such as Evernote, and Xero);

• Suppliers who offer outsourced backup only. In their case, there is no clearly established disaster recovery plan, as such. The customer then has to question the ability of the provider to restore backup files in the event of a disaster at the main site.
  Examples are intermediate suppliers (such as Zervant and Sellsy);

• Suppliers who don’t mention the issue or do not have anything in place. The subject of backup doesn’t even get raised, so it’s better to assume that nothing is being done.
  Small players are usually in this situation.

Getting contracts right is key

In the vast majority of cases, SaaS providers have no provisions in their contracts on how they will manage disaster recovery, even though they might stress their ability to handle that risk. In fact, contracts usually include default Act of God clauses stipulating that the supplier is not liable for a breach of contractual obligations if this is caused by an event beyond their reasonable control. The legal risks must therefore be addressed when framing the agreement, and these types of clauses should be removed to ensure an appropriate level of cover.

Just as they do when framing conventional contracts, customers must ensure that clear service level agreements are in place, in particular for disaster recovery. These need to cover:

• Recovery times (Recovery Time Objective – RTO) and data loss (Recovery Point – RPO) in the event of a disaster;

• The provider’s disaster recovery plan, including crisis management procedures, as well as the obligation to carry out conclusive tests every year with real-world scenarios, as part of the plan, with the customer having the option to review the test report;

• Financial penalties and the right to terminate the contract (in particular, with a provision to recover usable data) if commitments are breached.

IAAS/PAAS disaster recovery: THE CUSTOMER’S RESPONSIBILITY TO PUT IN PLACE

Infrastructure as a Service (IaaS) is a standardized, automated offering of computing, storage, and network resources owned and hosted by a provider, and made available to the customer on demand. A Platform as a Service (PaaS) offering is similar to an IaaS offer, but it is different in that it only applies to software development stack (database, EDI, business process management…) according to Gartner’s definition. Unlike SaaS, disaster recovery remains the customer’s responsibility in both cases: IaaS/PaaS providers make services available in various data centers, and the customer is responsible for their use and configuration. Two solutions are available to customers using these services: to entrust things to a provider, or manage it themselves.

The market for cloud disaster recovery is not a mature one

Cloud disaster recovery providers are referred to by the acronym DRaaS: Disaster Recovery as a Service. Initially, DRaaS providers offered cloud-based IS disaster recovery of an “on premise” datacenter. But, today, they also offer to provide recovery for infrastructure already in the cloud, such as AWS or Azure. Levels of maturity remain very variable, depending on the provider and which cloud is used. Some DRaaS providers require that their own cloud is used for recovery, which means they cannot offer a PaaS recovery service.

As with SaaS, there are no default contractual provisions. Therefore, any guarantees required for data loss or recovery time will need to be negotiated. Suppliers generally promise to be able to tailor their offer to the customer’s requirements! To ensure that the recovery performs correctly, the customer must plan for disaster recovery tests to be carried out regularly (we recommend once a year).

Operating your own disaster recovery plan, using tools offered by the supplier

For “on-premise” infrastructure, you will need to think about, and define, your DRP strategy right from the design phase. This strategy must include the option of performing tests to ensure a sufficient level of confidence in your plan.

Implementation can be simplified by the tools offered by cloud providers, and the high levels of standardization in cloud environments. The major players have set out, in white papers, the key guidelines to follow in pursuing such a project (for example, AWS and Azure).

Conceptually, these DRP strategies remain close to those used in “on-premise” data centers.

There are four main ones:

• backup and restore: simple backups of data and images of machines on a remote site, which are restored if an incident occurs;
• pilot light: replication of databases and the provision of machines, in the form of images, ready to be used if an incident occurs;
• warm standby: full replication of the main site (data and machines); the recovery site is undersized in performance terms but ready to scale up if an incident occurs;
• multi-site (or active-active): the two sites are identical and share the load from users. If an incident occurs, the remaining site can scale up to cover all users.

Hybrid solutions that are better designed to take account of recovery time requirements, and cost and complexity considerations, can also be considered.

The real contribution that the cloud can make to DRP is the numerous tools that it can offer to simplify its implementation and activation.

As a result, data replication can be simplified for asynchronous geo-replication options (where multiple copies are replicated to other regions). The RPO varies, depending on the types of data and tools involved. Aside from this option, local data redundancy is almost always included.

The high degree of standardization also makes it possible to automate the recovery: the scripts or APIs made available by providers make it possible to automate deployment of infrastructures, resize instances (according to previously defined configuration), distribute loads and traffic, carry out IP addressing, etc., in order to considerably speed up a backup site’s activation time.

The monitoring and alert tools, which are also on offer, are intended to facilitate in-service support and can be used to detect an incident in the shortest possible time, or in some cases, partially automate the activation of a backup site.

Lastly, this ability to provision new resources within a few minutes enables the associated OPEX to be minimized. By using such a strategy, it’s possible to make gains of 40 to 70% on the cost of DRP infrastructure.

Toward greater support by providers?

During 2017, Azure is planning to offer an option to provide recovery for virtual machines hosted on its platform by enhancing its “Site Recovery” service. In fact, “Site Recovery”, in its current form, offers to support traditional site backup, by using the Azure cloud to host the secondary site, but Microsoft wants to extend this service to provide a Recovery as a Service option. This tool would allow the automatic deployment of the secondary site (of the active-passive type), automatic data replication, and easier testing.

This option was available as a “public preview” at the end of May 2017. There is no equivalent project in train from the other main IaaS/PaaS providers.

THE CLOUD AND PROVIDER SYSTEMIC RISK

Backup of cloud-based services is dealt with differently, depending on the type of service used. SaaS recovery must be managed through contracts and are the responsibility of the provider, while IaaS/PaaS recovery, simplified by the tools available, remains the responsibility of the customer.

There is a risk of the widespread failure of a provider’s hosting region as recent incidents have shown. Even though these incidents have been short-lived, or have had minor impacts, the possibility of widespread failure cannot be ignored. The issue of cyber-resilience, then, must still be dealt with. Using a second cloud provider can cover the risk of destruction, or a major outage of a first provider’s infrastructure. This solution is very complex because portability between providers is a difficult issue. For now, there are few companies that have risked it, although  Snapchat is an example: it uses Google’s cloud for its production, and plans to use Amazon’s for its DRP within five years.

Cet article The Cloud: The end of IT backup – or a new way of doing it? est apparu en premier sur RiskInsight.

Le secours informatique SaaS, une responsabilité du fournisseur à formaliser

Un service SaaS (Software as a Service) est un logiciel mis à disposition et directement consommable depuis Internet. Il est géré et administré par un ou plusieurs fournisseurs.  Le client n’a donc pas la latitude nécessaire pour opérer le secours (pas d’accès aux données brutes, pas d’accès aux codes sources, ni aux applicatifs pour dupliquer l’infrastructure…), il doit donc s’en remettre au bon vouloir de son fournisseur.

Un niveau de couverture du secours informatique pour SaaS variable suivant la maturité du fournisseur

Trois grandes tendances se dessinent :

• Les fournisseurs qui disposent d’un plan de secours informatique inclus
  Dans le cadre de l’offre standard, le fournisseur assure un secours sur un datacenter distant, complété généralement par des sauvegardes externalisées. Il ne s’engage néanmoins que rarement sur les délais de reprise.
  Ex : les grands acteurs du SaaS (ex : Office 365, SalesForce, SAP…) , ainsi que certains acteurs de taille intermédiaire (ex : Evernote, Xero…) ;

• Les fournisseurs qui disposent simplement d’une sauvegarde externalisée
  En tant que tel, aucun plan de secours informatique n’est clairement établi. Le client doit alors s’interroger sur la capacité du fournisseur à restaurer les sauvegardes en cas de sinistre global sur le site principal.
  Ex : Des fournisseurs de taille intermédiaire (ex : Zervant, Sellsy…) ;

• Les fournisseurs qui ne communiquent pas ou n’en disposent pas
  Le sujet du secours informatique n’est pas abordé, il est donc préférable de considérer que rien n’est fait.
  Ex : Les acteurs de petite taille sont généralement dans ce cas.

L’importance de l’aspect contractuel

Dans la très grande majorité des cas, les fournisseurs SaaS ne s’engagent pas dans leur contrat sur leur façon de gérer le secours ; même lorsque ceux-ci mettent en avant leur capacité à traiter cette problématique. En effet, les contrats comportent généralement par défaut des clauses de Force Majeure stipulant que le fournisseur n’est pas responsable de manquement aux obligations du contrat dans la mesure où ce manquement est causé par un évènement en dehors de leur contrôle raisonnable. Le risque juridique doit donc être traité lors de la souscription et ces clauses supprimées pour s’assurer un bon niveau de couverture.

Lors de la souscription, comme pour des contrats classiques, les clients doivent s’assurer que figure bien des engagements de service, en particulier pour les secours informatiques :

• Le délai de reprise (Durée Maximale d’Interruption Acceptable ou DMIA) et les pertes de données (Perte de Données Maximale Acceptable ou PDMA) en cas de sinistre;
• Le plan de secours informatique du fournisseur incluant les modalités de gestion de crise ainsi que l’obligation de conduire plusieurs tests probants par an de ce plan avec la possibilité pour le client d’accès au rapport des tests ;
• Les pénalités financières et le droit de résilier le contrat (avec en particulier la récupération des données exploitables) en cas de manquement aux engagements.

Le secours informatique du IaaS/PaaS, une mise en oeuvre et une responsabilité du client

Le IaaS (Infrastructure as a Service) est une offre standardisée et automatisée de ressources de calcul, de moyens de stockage et de ressources réseau détenus et hébergés par un fournisseur et mis à disposition au client à la demande. L’offre PaaS (Platform as a Service) est similaire à celle du IaaS, à la différence près qu’elle ne concerne que les infrastructures applicative (définitions Gartner) Contrairement au cas du SaaS, le secours reste sous la responsabilité du client dans les deux cas : les fournisseurs IaaS/PaaS mettent à disposition des ressources dans différents datacenters et le client est responsable de l’usage et de la configuration qu’il en fait. Deux solutions s’offrent aux clients utilisant ces services : confier à un prestataire son secours ou bien le gérer lui-même.

Avoir recours à un prestataire de secours, un marché peu mature

Les prestataires de secours dans le Cloud sont désignés par l’acronyme « DRaaS » pour Disaster Recovery as a Service. Initialement, les fournisseurs DRaaS proposaient d’assurer dans le Cloud le secours de votre SI « on-premise ». Mais ils proposent également aujourd’hui d’assurer le secours de vos infrastructures déjà dans le Cloud, AWS ou Azure par exemple. La maturité reste très variable selon les fournisseurs et le cloud utilisé. Certains fournisseurs DRaaS imposent que le Cloud de destination du secours soit le leur, ne permettant pas ainsi de couvrir le secours de service PaaS.

Comme avec le SaaS, pas de garanties incluses par défaut quant aux pertes de données ou au délai de reprise, il faut les négocier. Les fournisseurs promettent de pouvoir s’adapter aux exigences du client ! Pour s’assurer que le secours fonctionne, le client doit prévoir la réalisation régulière de tests probants du secours (recommandation d’une fois par an).

Réaliser soi-même son secours en utilisant les outils proposés par le fournisseur

Comme sur une infrastructure « on-premise », il est nécessaire de réfléchir et définir sa stratégie de secours dès la conception. Cette stratégie doit intégrer la capacité de réaliser des tests probants permettant d’assurer un niveau de confiance suffisant dans son plan.

La mise en place est simplifiée par les outils mis à disposition par les fournisseurs Cloud et la forte standardisation des environnements Cloud. Les grands acteurs publient dans des livres blancs les grandes lignes directrices pour mettre en place un tel projet (par exemple AWS ou Azure).

Les concepts des stratégies du secours informatique restent proches de celles pour les datacenters on-premise.

On peut en dénombrer quatre principales :

• la sauvegarde et restauration: simple sauvegarde des données et images des machines sur un site distant, restaurées en cas de sinistre ;
• la veilleuse: réplication des bases de données et mise à disposition des machines sous forme d’images prêtes à être démarrées en cas de sinistre ;
• le secours à chaud: réplication complète du site primaire (données et machines), le site de secours est sous-dimensionné en termes de performances et est prêt à monter en charge en cas sinistre ;
• le multi site (ou actif-actif): les deux sites sont identiques et se partagent la charge des utilisateurs. En cas de sinistre, le site restant peut monter en charge pour accueillir la totalité des utilisateurs.

Des solutions hybrides pouvant mieux s’adapter aux exigences de délai de reprise, coût et complexité de la solution peuvent être envisagées.

Le véritable apport du Cloud pour le secours concerne les nombreux outils mis à disposition simplifiant la mise en œuvre et le déclenchement.

La réplication des données est ainsi simplifiée pour les options de géo-réplication asynchrones (plusieurs copies répliquées dans d’autres régions). La PDMA est variable en fonction des types de données et des outils proposés. Au-delà de cette option, une redondance locale des données est presque systématiquement incluse.

La forte standardisation permet également d’automatiser la reprise : les scripts ou API mis à disposition par les fournisseurs permettent d’automatiser le déploiement des infrastructures, le redimensionnement des instances en fonction de métriques précédemment définies, la répartition des charges et du trafic ou, l’adressage IP etc… afin d’accélérer de façon significative l’activation d’un site de secours.

Les outils de surveillance et alerte qui sont également proposés visent à faciliter le Maintien en Conditions Opérationnelles (MCO) du secours et peuvent être utilisés pour détecter au plus tôt un incident voire, dans certains cas, automatiser partiellement le déclenchement du secours.

Enfin la capacité à provisionner des nouvelles ressources en quelques minutes permet de limiter l’OPEX. A stratégie équivalente, il est ainsi possible d’avoir des gains de 40 à 70% sur le coût du secours !

Vers une plus grande prise en charge par le fournisseur ?

Azure prévoit une option, courant 2017, pour assurer le secours des machines virtuelles hébergées au sein de leur plateforme via la complétion de leur service « Site Recovery ». En effet, « Site Recovery » propose à l’heure actuelle de prendre en charge le secours de site traditionnel en utilisant le cloud Azure pour accueillir le site secondaire, mais Microsoft souhaite étendre ce service au secours de leurs propres infrastructures. Cet outil permettrait un déploiement automatique du site secondaire (de type actif-passif), une réplication automatique des données et une mise en place de tests facilitée.

Cette option est passée en « public preview » fin mai 2017. Un projet équivalent n’est pas d’actualité chez les autres principaux fournisseurs IaaS/PaaS.

Le cloud face au risque systémique des fournisseurs

Le secours informatique des services hébergés dans le cloud s’aborde différemment selon le type de service utilisé. Le secours du SaaS doit être géré contractuellement et est sous la responsabilité du fournisseur tandis que le secours du IaaS/PaaS, simplifié par les outils, reste sous la responsabilité du client.

Le risque de défaillance généralisé d’une région d’hébergement d’un fournisseur existe comme le montre les derniers incidents. Même si aujourd’hui, les incidents ont été de courte durée ou avec des impacts fiables, une défaillance généralisée ne peut pas être ignorée. Reste donc à traiter la problématique de cyber-résilience. L’utilisation d’un 2^ème fournisseur cloud permet de couvrir le risque de destruction ou d’indisponibilité majeure des infrastructures du premier. Cette solution reste très complexe car la portabilité d’un fournisseur à un autre est délicate. Pour l’instant, peu d’entreprises s’y sont risquées, même si l’on peut citer l’exemple de Snapchat qui utilise le cloud Google pour sa production et prévoit d’utiliser celui d’Amazon pour son secours d’ici à 5 ans.

Cet article Le Cloud, la fin ou renouveau du secours informatique ? est apparu en premier sur RiskInsight.

Une adoption motivée par réduction des coûts et recherche d’agilité

Malgré la dynamique du marché et la promesse de gains sous-jacente, les DSI des grandes entreprises tardent à se mettre en mouvement, réagissant plus au Cloud qu’elles ne l’anticipent. Elles le privilégient essentiellement pour des usages à risques techniques limités et à ROI rapide, principalement en IaaS et en SaaS.

SaaS : une utilisation massive des services standardisés

Le SaaS est aujourd’hui le principal vecteur d’adoption du Cloud. L’adoption du SaaS est centrée sur les fonctions support dont l’usage est standardisé (bureautique, messagerie, CRM, paie…). Le SaaS est également fortement sollicité pour les services de sécurité (antivirus, proxy, services de tests d’intrusion…) qui nécessitent une puissance de calcul importante, des évolutions en cycle court ainsi qu’une disponibilité maximale pour des employés de plus en plus mobiles.

PaaS : une adoption encore confidentielle

C’est le segment le moins bien appréhendé par les grands groupes aujourd’hui. Il correspond à la fourniture d’une plateforme d’exécution de code informatique. Il permet la mise à disposition d’une application en limitant très fortement les opérations sur les couches sous-jacentes (systèmes, bases de données, serveurs d’applications…). Le PaaS reste aujourd’hui cantonné chez les grands comptes à des usages « jetables », comme des prototypes ou des sites web temporaires (événementiels).

IaaS : des déploiements essentiellement en mode « privé »

Le modèle IaaS, fourniture de machines virtuelles (VMs) et ressources associées depuis un Cloud, qu’il soit public ou privé, permet d’introduire davantage d’agilité. Les grandes entreprises déploient aujourd’hui beaucoup de IaaS privés, dans l’optique de capitaliser sur leurs compétences internes et leurs investissements en infrastructures. De son côté, le IaaS public est mis en œuvre de façon très ciblée, par exemple pour une filière web, ou dans une logique de « bac à sable ».

Pour autant, grâce à la consolidation à grande échelle, c’est le modèle public qui permet d’obtenir les gains fonctionnels et financiers les plus importants. C’est pourquoi les stratégies de déploiement de IaaS privés sont ou doivent être considérés comme une étape sur une trajectoire plus ou moins long terme de généralisation d’IaaS public.

Un avenir qui promet plus d’innovation et de valeur ajoutée

La 1ère phase d’adoption du Cloud est motivée par la recherche d’économies et l’optimisation du niveau d’agilité. Ces prochaines années, le marché devrait évoluer pour offrir des solutions avec une valeur ajoutée de plus en plus forte, pour répondre à la fois aux offreurs en quête de relais de croissance et aux entreprises utilisatrices souhaitant optimiser leur marge en se recentrant sur leur cœur de métier.

Le SaaS devrait s’imposer dans les entreprises comme le choix par défaut. Les éditeurs de logiciels vont proposer de manière systématique leurs solutions en mode SaaS, en partenariat avec les fournisseurs IaaS. Ils s’assureront ainsi des revenus constants et proposeront à leurs clients des services très industrialisés, flexibles et au meilleur coût.

L’usage du PaaS devrait exploser lorsque les problématiques de portabilité des applications, bien souvent surestimées, seront résolues. Il devrait alors devenir le socle d’exécution par défaut de toutes les applications qui ne seraient pas consommées en SaaS. Ces plateformes vont s’enrichir pour fournir aux développeurs un maximum d’accélérateurs et de nouvelles possibilités (composants et connecteurs pré-packagés, services de sécurité, réseaux de distribution de contenus… ) et donc en faire un choix par défaut dans les filières de développement.

Par ailleurs, les éditeurs de progiciels devraient rapidement proposer leurs solutions en mode pré-packagé pour les plateformes PaaS du marché. Le IaaS devrait perdurer pour adresser des besoins applicatifs très spécifiques. Mais il ne permettra pas d’aller chercher toutes les économies d’échelle d’une approche Cloud.

 Ce sont le SaaS et le PaaS qui porteront le marché demain.

Cet article Le Cloud : quelle réalité marché derrière les nuages ? est apparu en premier sur RiskInsight.

Le Cloud impose-t-il une évolution forcée ?

Le Cloud simplifie l’accès à l’outil informatique en focalisant l’énergie de l’utilisateur sur le choix du service plutôt que sur la démarche de mise en œuvre. Cette facilité d’accès à des services « clé en main » peut inciter les Métiers de l’entreprise à traiter directement avec les offreurs Cloud sans impliquer la DSI. Pour contrôler l’adoption des services Cloud, la DSI doit devenir un acteur incontournable de ses Métiers : non pas en s’imposant mais bien devenant un partenaire légitime du Métier, apporteur de valeur ajoutée aux services Cloud.

Une priorisation des chantiers nécessaire

Le Cloud n’est pas qu’un outil technique à destination de la DSI seule. Il est essentiel de mettre en place sa stratégie Cloud en impliquant la Direction de l’entreprise pour prendre en compte l’existant et les besoins à venir, en déduire le périmètre éligible et enfin choisir ses modèles de sourcing (Public et/ou privé) et le type de Cloud (IAAS, PAAS et/ou SAAS) adapté aux cas d’usage. Deuxième étape pour la DSI : promouvoir cette stratégie auprès des Métiers avec ses sponsors en valorisant les apports de la démarche et en éclairant les contraintes liées à son utilisation.

A ce stade la DSI devra choisir entre 2 positionnements :

1) Un accès direct des métiers aux fournisseurs Cloud

La DSI ne porte pas la responsabilité du choix des fournisseurs mais apporte son expertise sur les dimensions :
•    Contractuelles, en mettant à profit l’expérience de la DSI pour définir les engagements en matière de niveau de service, de traçabilité, de pilotage des coûts…
•    Techniques, en accompagnant les projets sur l’intégration des services Cloud dans le SI de l’entreprise tout en respectant les contraintes internes de sécurité et d’échanges de données
•    Légales, en apportant sa connaissance des contraintes liées à l’hébergement des données (données personnelles, données sensibles d’entreprise, législation française, contraintes sectorielles…)
•    De réversibilité technique et opérationnelle, pour préparer en amont le désengagement d’un fournisseur.

2) Une DSI « broker de Cloud »

La DSI se positionne comme l’interlocuteur unique à la fois du Métier et des fournisseurs Cloud.  Le rôle d’expertise reste d’actualité et voit son périmètre étendu par une fonction de gestion des  relations clients et fournisseurs. La DSI est alors en responsabilité :
•    D’intégrer des services Cloud technique ou métier au catalogue de la DSI
•    De piloter et de garantir la qualité des services exposés par la DSI
•    De définir et de mettre en place les outils permettant une intégration au SI des services Cloud (IAM, échanges, service management…)
•    De faire évoluer ses processus internes pour fournir un service utilisateur unifié indépendamment des modes de sourcing
•    Et bien sûr, de fournir ces services Cloud au meilleur coût du marché à ses utilisateurs !

Bien que la stratégie de positionnement soit à définir suivant le contexte particulier de chaque entreprise, une majorité aura intérêt à adopter un positionnement « broker de Cloud ». Ce positionnement permettra de définir une stratégie IT globale cohérente entre les besoins internes et les possibilités offertes par les fournisseurs. Elle permettra ainsi de tirer toute la valeur économique et qualitative d’une approche Cloud par le biais d’achats massifiés et intégrables de manière standardisée au SI.

Les « temps métiers » et les « temps IT traditionnels» n’ont plus la même échelle, le Cloud est un des vecteurs de transformation qui permet de contribuer à la performance globale de l’entreprise. Néanmoins, pour combler ce décalage, la DSI doit être en perpétuelle transformation pour fournir les moyens nécessaires aux ambitions de l’entreprise.

Cet article Le Cloud computing : vers une DSI orientée service ? est apparu en premier sur RiskInsight.

La sécurité, une question négligée après la phase de contractualisation

Les limites posées par le SaaS sont aujourd’hui bien connues : difficultés d’adaptation du service aux besoins de l’entreprise, absence de possibilités d’audit, questions réglementaires, etc.

Pourtant, de plus en plus de services cloud sont adoptés, sans que la sécurité ne soit nécessairement un frein. Pour cela, une démarche classique d’analyse de risque est menée en évaluant les contraintes légales / réglementaires,  les mécanismes de protection des données, la gestion de la sécurité par le fournisseur, ou encore les conditions de réversibilité de la donnée.

Cette démarche est de plus en plus maîtrisée : de nombreux retours d’expérience et un outillage qui se professionnalise* amènent à faire des choix éclairés, en toute connaissance de cause des risques encourus, et donc parfois acceptés.

Malheureusement, la démarche sécurité s’arrête souvent là : à partir du moment où le sujet a été traité lors de la contractualisation, on considère qu’un bon niveau est assuré, puisque l’on a exigé du prestataire de s’en occuper !

Le maintien de la sécurité dans le temps est un enjeu régulièrement oublié, alors même qu’il est en partie du ressort de l’entreprise, et pas seulement à la charge du fournisseur.

Des sujets à inscrire dans la durée

Pour s’assurer que la solution cloud est déployée avec le bon niveau de sécurité, et maintenir celui-ci dans le temps, quatre grands thèmes sont à aborder en priorité. S’il s’agit de bonnes pratiques habituelles sur un SI d’entreprise, il faut aujourd’hui les adapter, voire les renforcer pour le SaaS.

•  La gouvernance : les services SaaS doivent être intégrés aux procédures de sécurité et des processus liés au service fourni. Il peut par ailleurs être utile de mener des actions de sensibilisation dans certaines situations.

• L’administration fonctionnelle du service est bien du ressort de l’entreprise : le fournisseur n’est pas en mesure de faire les choix fonctionnels à votre place (et ce n’est souvent pas ce qu’on lui demande) ! Pour l’aspect sécurité plus encore, c’est à l’entreprise de définir  et mettre en œuvre les fonctionnalités avancées disponibles, de restreindre les services au minimum requis par l’utilisateur, de former ses administrateurs… Ces aspects sont souvent les plus négligés, comme nous le constatons lors des audits que nous réalisons.
• Des contrôles réguliers peuvent et doivent aussi être mis en œuvre sur les parties auditables des services. Il s’agit en particulier de vérifier que les paramètres de sécurité sont inchangés, d’exploiter les logs sécurité, et de revoir les habilitations. S’il le permet, enfin, ne pas hésiter à auditer son fournisseur (visites de site, voire tests d’intrusion).
• Il reste enfin à traiter le sujet de l’IAM, enjeu transverse du Cloud, souvent peu ou mal maîtrisé de par sa complexité. Même si cette voie est souvent suivie, il faut pourtant éviter de recréer un compte dans le Cloud pour chaque utilisateur. Pour « synchroniser » les identités de l’entreprise dans le Cloud, il faut également éviter la multiplication des connecteurs  (et notamment ne pas en redévelopper un par fournisseur), sous peine de créer une situation ingérable. Deux approches sont aujourd’hui à prioriser : soit l’utilisation d’un outil de fédération d’identités interne (qui réalise la connexion avec la majorité des fournisseurs de SaaS), soit l’externalisation de l’IAM… dans le Cloud (!) en « Identity as a Service »

Le RSSI, garant de la cohérence des projets

Dans le cas du SaaS, le rôle des responsables sécurité de l’information est double.

D’une part, il s’agit d’accompagner les projets, en leur apportant des solutions transverses : un certain nombre de points peuvent être mutualisés en amont. C’est tout particulièrement le cas des sujets tels que l’IAM, qui doivent faire l’objet d’une approche unifiée et cohérente –  et surtout pas projet par projet.  C’est également le cas des questions légales qui doivent faire l’objet d’une réflexion globale amont.

D’autre part, la SSI demeure la garante du niveau de sécurité dans le temps : la Gestion Opérationnelle de la sécurité devra faire l’effort de partir à la conquête des nuages !

* On peut citer notamment le guide publié par l’ANSSI et la « Cloud Control Matrix » maintenue par la Cloud Security Alliance

Cet article SaaS et sécurité : entreprises, ne mettez pas vos responsabilités dans les nuages ! est apparu en premier sur RiskInsight.

1 – Comprendre le cloud et démystifier ses complexités

L’actuel CloudWashing ne facilite pas la compréhension des différents modèles de services et des bénéfices réels que les grands comptes peuvent en tirer. C’est pourquoi, il est nécessaire de commencer par mener un état de l’art pour comprendre les principes de consommation de ressources banalisées prêtes à l’usage et de segmentation des ressources, les différences avec les précédentes approches (ASP pour le SaaS, outsourcing pour le IaaS) mais aussi les spécificités, niveaux de maturité, bénéfices et complexités propres à chaque modèle.

Contrairement à ce que l’on pourrait penser, les complexités à adresser dans le cadre du cloud public ne se limitent pas à la dimension technologique et doivent être adressées en continu  :

• Complexités organisationnelles : le rôle de la DSI passe du pilotage de ressources à celui de pilotage de fournisseurs (c’est là la fin du mythe du super administrateur !) ;
•  Complexités réglementaires : réversibilité contractuelle, confidentialité, contraintes sectorielles ou légales sur le stockage des données ;
• Complexités technologiques : services d’intégration au SI, forte dépendance au réseau, etc.

2 –  Identifier  les opportunités d’externalisation de services

L’état de l’art permet d’identifier les cas d’usages aujourd’hui possibles dans l’entreprise :

• Le SaaS de par les fonctions génériques qu’il propose est envisagé pour des besoins non spécifiques au cœur de métier avec une faible intégration au SI ;
• Le PaaS public de par l’hétérogénéité des services offerts et le manque de standards est considéré pour les besoins « jetables »  surtout pour des organisations qui ont déjà investi sur leurs filières de développement basées sur des technologies traditionnelles ;
• Le IaaS privé s’inscrit en continuité de l’industrialisation des infrastructures en permettant plus d’agilité via le self-service ;
• Le IaaS public  ou hybride permet quant à lui d’adopter une position de « broker » d’infrastructure modulant le coût et la QoS en fonction des besoins métiers tout en étant capable de fournir une réponse agile à un besoin ponctuel de débordement de capacité.

Il est alors possible de s’appuyer sur un modèle comme SOI (méthodologie de catalogue de services) pour décliner les opportunités d’externalisation de services dans le cloud.

3 –  Affiner le périmètre éligible et définir la cible

Cette troisième étape commence par l’inventaire des critères d’éligibilité techniques et métiers (criticité des applications, environnements de développement, DMZ, étude des coûts …). Le business case est une étape clé et peut notamment révéler des coûts d’exploitation plus importants (par exemple dans le cadre du IaaS dès lors que l’utilisation des serveurs est intensive). L’application de ces critères permet alors de construire et de prioriser un portefeuille de projets. Une démarche usuelle mais avec des spécificités  propres au cloud s’impose :

• Commencer les déploiements par un périmètre pilote afin d’instruire plus facilement et à plus petite échelles les changements organisationnels ;
• Identifier des quick wins opportunistes et les adresser à l’issue du pilote sur des applications avec peu de contraintes technologiques ;
• Puis généraliser les déploiements et mener une politique du changement.

4 – Transformer le SI pour le cloud

Dès lors que les déploiements en mode cloud vont se généraliser, des applications de plus en plus en lien avec le cœur du SI vont partir vers le cloud. Se pose alors la problématique d’intégration aux services du SI. Les transformations à opérer sur le SI seront alors la prochaine étape dans l’odyssée vers le cloud …

Cet article 2012, l’odyssée du cloud : comment bien préparer votre voyage ? est apparu en premier sur RiskInsight.

Les projets de relation clients digitale, à la croisée de différents métiers et donneurs d’ordre sont compliqués à financer. Quelle stratégie de financement adopter ?

De tels projets portent en effet de nouvelles pratiques métiers et induisent des outils et automatismes adaptés à chaque canal. L’appréciation du coût d’un projet doit tenir compte de ces nombreux aspects matériels, logiciels et mais aussi d’accompagnement du changement. Les coûts de mise en œuvre représentent pas moins de 50% des dépenses (voir schéma ci-dessous).

Que la stratégie soit par investissements progressifs ou d’investissements d’ampleur il est recommandé de cadrer périmètre et trajectoire très en amont pour que tous les acteurs concernés adhèrent à la stratégie de financement.

Cette approche permet d’anticiper les besoins en fonctions socles (référentiels, middleware) ou mutualisées (outils de pilotage, reporting) et de répondre de manière progressive aux besoins immédiats des métiers, friands de nouveaux services (chat, FAQ, services en ligne, SFA).

Sur le plan matériel et logiciel, vaut-il mieux investir ou louer ? Que penser du SaaS ?

Dans des contextes de restriction budgétaire comme on peut les connaître aujourd’hui ou si une très forte réactivité de la DSI est demandée par les métiers, les offres en mode SaaS apparaissent  de plus en plus séduisantes.

Les solutions disponibles sont maintenant satisfaisantes sur le plan de la couverture fonctionnelle. Elles permettent d’accélérer la mise en œuvre. Leur usage est réversible et se prête à l’expérimentation. Il est donc primordial, encore une fois, d’anticiper. Anticiper au maximum les demandes ou intérêt des métiers pour ces services.

Il convient toutefois garder à l’esprit trois éléments.

Le point mort financier se situe généralement entre 2 et 4 ans d’usage, période au-delà de laquelle un achat reste préférable.

Ensuite le poste métier le plus candidat au mode SaaS est celui qui nécessite le moins d’intégration autour des données clients, par exemples les populations commerciales B2B.

Enfin, le mode SaaS permet de s’appuyer sur des services métiers et compétences spécifiques à la relation client, par exemple la gestion de la délivérabilité des emails, ce qui représente un véritable avantage.

Comment justifier les investissements ? Quelles pistes de gains ?

La mise en œuvre de la multicanalité porte la piste de gains la plus évidente, le différentiel de coûts entre canaux physiques et digitaux favorise en effet la relation client digitale. Par exemple pour un budget équivalent, une direction marketing peut multiplier par 8 à 10 le nombre de messages sortants en favorisant l’emailing.

 Trois grandes natures de gains sont à étudier. Des gains qui peuvent être quantitatifs ou qualitatifs : création de valeur (fidéliser – développer), efficacité opérationnelle (maîtriser le coût des interactions clients – optimiser ses ressources), perception de la marque (faire du client et du collaborateur un ambassadeur).

Les gains sont à apprécier avec les métiers donneurs d’ordre sur la base du périmètre des besoins exprimés. L’étude d’un business case doit donc être anticipée avec les métiers dès le cadrage du projet.

Vous l’aurez compris, dans le financement de la relation client digitale, s’il n’y avait qu’un seul mot d’ordre à retenir : anticipez !

Cet article Comment financer son projet de relation client digitale ? est apparu en premier sur RiskInsight.

Véritable transformation du SI, l’« informatique dans les nuages » s’accompagne de nouveaux besoins, nouvelles pratiques et d’un nouveau modèle économique. A l’ère des investissements lourds en Datacenter et infrastructures succèderont les services hébergés, facturés à l’usage.

Les offres Cloud du marché IT  couvrent l’ensemble des modèles de services Cloud : IaaS (Infrastructure as a Service), PaaS (Platform as a Service) et SaaS (Software as a Service).

Aussi, on retrouve sous la bannière du Cloud des acteurs allant de l’éditeur de logiciels à l’acteur issu du monde de l’e-business en passant par l’expert en solutions de virtualisation….ou l’opérateur de Télécoms.

Que font les opérateurs télécom dans les nuages ?

Pour déployer l’ensemble des services Cloud, la base est indispensable ; et cette base, c’est l’IaaS – les infrastructures…

Experts dans la conception, la production et l’exploitation de solutions de communications entreprises, les opérateurs ont donc une carte à jouer.

Certains opérateurs proposent déjà des offres Cloud, à base de solutions de virtualisation d’infrastructure et d’accès réseaux à la carte / à la demande. C’est le cas de Verizon Business avec CaaS (Computer as a Service)  et de l’offre Flexible Computing d’Orange business Service, déclinée en version premium depuis Décembre 2010. SFR a de son côté lancé en France une offre Infrastructure SI à la Demande le 30 juin dernier. L’opérateur s’est pour cela allié à HP qui fournit l’expertise Infrastructure manquant à l’opérateur.

Des atouts indéniables

Les opérateurs de télécoms bénéficient d’une notoriété et d’un capital confiance inégalés dans le monde des solutions et services informatiques. Par ailleurs, alors que sécurité et  dépendance au réseau sont évoqués comme des freins majeurs, ils y offrent des réponses concrètes.

– Sécurité : les opérateurs proposent des solutions d’interconnexion d’utilisateurs, de sites ou d’infrastructures sécurisés depuis plusieurs années.

– Dépendance au réseau : les opérateurs exploitent des solutions Très Haut Débit de moins en moins chères, avec une disponibilité bien souvent garantie à 100% et des engagements de niveaux de service associés.

Ils disposent en outre d’avantages concurrentiels établis sur ce marché (clientèle mixte entreprises et grand public, expertise en infrastructure et réseau, couverture globale et capacité d’intervention IT locale) et sont rodés au modèle économique de facturation à l’usage, caractéristique du Cloud.

Un positionnement appelé à évoluer

Le positionnement des principaux offreurs du marché se veut de plus en plus « généraliste ». Après avoir capitalisé sur leurs cœurs de métier respectifs (édition, gestion d’infrastructures, réseau) ils cherchent à élargir l’empreinte de leurs offres.

Pour les opérateurs notamment, cela passe par des alliances stratégiques avec les offreurs actifs sur les autres couches de la pyramide. Par exemple, Orange Business Services s’allie à Microsoft pour intégrer des solutions de messagerie et de collaboration de la plate-forme Microsoft Office 365, hébergée dans le Cloud. Dans ce cas, l’opérateur global qu’est France-Télécom Orange, met également à profit son savoir faire et ses ressources disponibles dans l’intégration de solutions informatiques.

Quelles perspectives ?

Le marché du Cloud n’en est vraisemblablement qu’à ses débuts, mais il dispose d’un potentiel de croissance fort que dénotent les investissements consentis sur le sujet et les premiers bilans économiques.

On ne compte plus les parallèles pour évoquer cette croissance attendue, par exemple avec la VoIP, un marché aujourd’hui mature et au cœur de la sratégie des opérateurs de télécoms.

Selon la plupart des acteurs du Cloud que j’ai pu rencontrer, ce marché représenterait 50% du marché total de l’IT dans le monde à horizon 5 ans. Ce palier de 50% demeurera la limite « physique » de développement du Cloud, tout l’IT n’ayant pas vocation à « basculer ».

Pour les analystes il devrait peser en 2015 dans le monde, entre 200 Mrd$ et 500 Mrd$. Le marché Français pourrait être estimé entre 10Mrd€ et 20Mrd€ cette même année (estimation Solucom).

Il y a fort à parier que Stéphane Richard, Directeur Général du groupe France Télécom, avait ces chiffres en tête en l’identifiant comme levier de croissance clé dans le cadre du plan stratégique « conquêtes 2015 ». Chiffres qui vont avec la certitude que les opérateurs disposent des atouts pour qu’une part importante du gâteau leur revienne d’ici 2015.

Cet article Les opérateurs, acteurs naturels du cloud computing est apparu en premier sur RiskInsight.