Apps – VSPC Partie 1 : Théorie

Architecture & Best Pratices

L’architecture va lourdement dépendre de ce que nous souhaitons faire. Dans le cadre d’un Fournisseur de Service Administré (MSP¹), une architecture 2 tiers est préférable car pour des raisons de sécurité nous pouvons être amené à publier le service à nos clients.

A l’exact opposé, pour un usage strictement interne (PME² et GE³) nous pouvons entrevoir un serveur mutualisé. Toutefois et sans raison valable, je déconseille fortement cette architecture et ce pour des raisons évidentes de sécurité.

La VSPC⁴ est composée de deux rôles majeurs. Une partie client WEB accessible à travers un navigateur et une seconde partie BDD⁵ sur un moteur MSSQL⁶. Maintenant que les 2 rôles sont posés, vous pouvez comprendre les deux paragraphes précédents. J’ai pris la résolution (bonne ou mauvaise) de faire des articles moins long, mais je n’ai pas pour autant décidé de me simplifier la vie. 🙂

Pourquoi faire simple après tout ?

La topographie et cartographie réseau est explicite. Néanmoins, j’aime entrer dans le détail.

Ce schéma peut paraitre au premier abord complexe à lire. Nous devons retenir pour la VSPC les composants ci haut VSPC Server qui hébergera la BDD et la console WEBUi. Cette dernière ayant pour vocation à être publié au client des infrastructures managées il est primordiale d’isoler cette dernière dans une DMZ⁷ et de définir une politique d’accès strict sur notre UTM⁸. Un filtrage sur les IPs entrantes et un petit PAT⁹ est là le strict minimum.

Je pense important de voir rôle par rôle l’ensemble des flux et identifier précisément ces derniers

Et donc dans l’idée, nous pourrons par la suite interagir avec les produits et services suivants (j’aime ce côté planétarium et cette maitrise de paint. On sent là les compétences acquises en L3).

Système & Performance

Comme toujours, la documentation est bien faite chez VEEAM et cela fait plaisir de ne pas à avoir à chercher à droite, à gauche dans un onglet ouvert et de sauté d’article en article.

Pour gagner du temps, c’est par là (clique ici).

Bon, je ne vais pas prendre la main de chacun concernant les performances et le type de système à déployer. Toutefois, il y a quelques points de vigilance. Il est important de s’assurer que l’ensemble des questions aient une réponse avant de se lancer à corps perdu dans le déploiement de la VCC¹⁶ et VSPC.

• Mon infrastructure est elle compatible pour accueillir les services VSPC en réseau isolé ?
  • Au minima une DMZ et un vlan dédié aux serveurs VSPC/VCC

• La version des composants VEEAM Tiers déjà en production sont elles prisent en charge par la VSPC (et VCC) ?
  • S’assurer de la compatibilité des versions. Il suffira de suivre la documentation et de réaliser l’upgrade des plateformes si besoin. Dans le pire des cas, il faudra refaire les serveurs pour incompatibilité d’OS¹⁷. Le pire du pire, l’infrastructure n’est plus capable de supporter les OS demandés.

T’es chié quand même ! Tu nous dis plus haut que tu ne vas pas traiter de la VCC, mais tu abordes tout de même le sujet…

C’est bien l’un des avantages et inconvénients de la solution. Il est difficilement possible de parler de l’un sans évoquer l’autre. Cela revient à parler choucroute sans évoquer le type de bière ou le riesling que l’on va servir avec… Gardons à l’idée qu’il ne faut pas se fermer de porte et si nous souhaitons demain proposer le service VSPC (un peu le but premier de l’outil) il nous faudra déployer un environnement VCC. Revenons aux questions…

• La version des composants additionnels (pour ne pas dire plugins) ainsi que la version des produits VEEAM déployés sur les infrastructures clientes sont elles compatibles ?
  • Comme pour notre infrastructure et les produits présent il conviendra d’enclencher les actions adéquates. Bien que cela concerne un client, une petite prestation journalière de la part d’une main intelligente ferait toujours plaisir aux finances.

Dernier point et non des moindres, il est possible de forcer la version du TLS¹⁸ en 1.2 lors de l’installation de la partie console. Prenez vos précautions car cela peut être sans pitié une fois l’installation terminée (oui dans mon cas ça s’est terminée partiellement en sueur, avec des larmes et quelques gouttes de sang…).

Bien que pour certains professionnels de l’informatique ce n’est pas grave, nous devons rester en TLS 1.0. Vous la voyez arrivée la douille ? Hé ba voilà, nous avons attrapé une bonne chaude pi**e des familles. C’est ça d’aller courir la fille sans capotes… la pénicilline nous sera d’aucun secours ici. #HEIN?

Décidément la sécurité, ce n’est pas pratique. <3

Access & Less Privileged

Le sujet va être vaste. Néanmoins, il est important de dissocier deux types de privilège.

• Les privilèges d’administration : propres au bon fonctionnement ainsi qu’à la sécurité de l’environnement, du SE jusqu’au SGBD¹⁹
• Les privilèges d’utilisation : propres à l’utilisation de la solution

Dans les deux cas, cela va concerner l’ensemble des produits liés à la VSPC. De facto, j’ai déjà traité dans les articles concernés les produits concernés. C’est pourquoi j’orienterai uniquement les articles sur la VSPC côté serveur comme console (pour la VCC, le facteur n’est pas passé…).

L’ensemble des permissions sont résumé pour l’infrastructure dans la partie suivante du guide.

Côté Serveur – SE

Naturellement et vous l’aurez compris, un compte de service sera nécessaire pour que notre serveur VSPC puisse fonctionner. Ce dernier doit avoir les droits d’administrateurs locaux.

Le plus simple à mon sens est donc de lui donner ce qu’il souhaite et de restreindre par la suite ce compte. C’est à dire ne lui donner les droits d’ouverture de session en tant que service et de lui refuser l’ouverture de session pour les autres types. Un petit coup de stratégie locale et nous en parlons plus. Personnellement je vous recommande l’approche type AGDLP²⁰ pour une bonne administration (j’ai envie de dire la base).

Si nous avions opté pour un serveur VSPC joint à un domaine, il aurait dans ce cas suffit de traiter ce point à travers une GPO²¹ et de faire appel une nouvelle fois au principe fondamental de l’AGDLP.

Côté Serveur – BDD

Côté SGBD, les droits nous sont donnés. Toutefois, je suis vraiment has been sur cette partie… Hé oui ça arrive. Je vais faire un chapitre, que dis je un article sur le sujet. Je n’ai jamais eu à administrer une BDD SQL de fond en comble.

Le métier de SysDBA²² (oui c’est un métier :p ) est un job bien à part, et ne s’improvise pas qui veux SysDBA oracle ou SQL.

Pour les droits, j’ai laissé les droits du wizard. Sinon, se référer plus haut au guide.

Côté console

C’est un peu particulier car sur le serveur dédié à la partie console, il ne convient QUE de respecter les bonnes pratiques liées à un SE. Toutefois, le compte d’administrateur local servira dans un premier temps à configurer notre serveur VSPC.

Néanmoins et je pense que tout le monde se joindra à cette idée, nous ne pouvons pas utiliser ce compte pour l’administration… Et cela même s’il notre serveur est en DMZ et non joint à un domaine.

Avant tout malentendu, il faut comprendre que notre compte administrateur est celui du serveur VSPC et non du compte où se trouve la web console. Donc si nous souhaitons ajouter un nouvel utilisateur lié au système d’exploitation il sera nécessaire de créer un compte utilisateur local ou un compte utilisateur du domaine. Dans les deux cas, les droits doivent être en adéquation côté SE.

Nous allons ensuite binder le compte système à un profil VSPC

Permissions	Description
Portal Administrator	Dieu parmi les Hommes, les utilisateurs avec ce profil peuvent administrer l’intégralité de la plateforme VSPC
Site Administrator	Les utilisateurs ayant ce profil peuvent uniquement administrer le site concerné (site Cloud Connect naturellement) et donc ont une vue limitée à leur environnement et produits.
Portal Operator	L’utilisateur avec le rôle opérateur du portail VSPC pourra manager uniquement les activités propres à une ou plusieurs entreprises (dans le sens compagnies) et non sites.
Read-Only User	L’utilisateur pourra uniquement surveiller et accéder aux données remontées dans la console pour une ou plusieurs compagnies.

Il est également possible si nous le souhaitons de définir des droits par groupe. Et j’oubliais le plus important nous pouvons renforcer la sécurité en implémentant de la MFA. Sur ce dernier point et si nous nous en référons à notre schéma réseau, les flux NTP doivent être ouvert.

Ok, c’est bien de faire des droits utilisateurs par utilisateurs. Mais tu vois, je suis un gars de la nouvelle génération moi. Je veux du SSO²³, un truc moderne. M’sieur l’rédacteur, il me faut du SSO, DU SSO !!!!

T’inquiète mon gars, la VSPC sait répondre à tes besoins. Toujours sur le même principe de rôle, il sera possible de mettre en place une jonction avec :

• ADFS
• Keycloak
• Okta
• Custom

Franchement c’est plutôt cool non ?

Licensing

Le sujet qui fâche… Mais cela fâche t-il vraiment ? L’outil proposant un grand nombre de fonctionnalités de gestion et de surveillance des produits VEEAM pour plusieurs sites et plusieurs entreprises il est normal de mettre la main au portefeuille ?

Je m’adresse ici au DAF et DSI des ESNs qui sont revendeurs et garants des produits VEEAMs, pensez à l’efficience et les valeurs ajoutées que vous allez générer. Cela sera un plus pour vos clients comme pour vos équipes internes quant à la notion de Service que vous prodiguerez.

Usage	Types	Descriptions
Commercial	Rental	La licence classique limité dans le temps selon la durée souscrite.
Commercial	Suscription	La licence est orientée pour un usage VCC limité dans le temps dans un abonnement de 1 à 5 ans. Une contrainte toutefois car l’entreprise doit avoir un contrat d’entreprise Microsoft ou de Licence VMWare.
Gratuit	Evaluation	Licence valable uniquement pour une période de 30 jours. A condition que le mode évaluation est choisie lors de l’installation.
Gratuit	NFR	Licence utilisé et limité dans le cadre de démonstration, entrainement et éducation. L’usage à la revente est interdit.

Je pense qu’avec tout cela, nous sommes suffisamment armés pour déployer et configurer notre infrastructure VSPC (sans VCC pour l’instant).

Apps – VSPC

Partie 2 : Pratique —>

1. MSP : Managed Services Providers ↩︎
2. PME : Petites et Moyennes Entreprises ↩︎
3. GE : Grandes Entreprises ↩︎
4. VSPC : VEEAM Service Provider Console ↩︎
5. BDD : Base de Données ↩︎
6. MSSQL : Microsoft SQL Serveur ↩︎
7. DMZ : Demilitarized Zone ↩︎
8. UTM : Unified Threat Management ↩︎
9. PAT : Port Address Translation ↩︎
10. RPC : Remote Procedure Call ↩︎
11. CRL : Certificat Revocation List ↩︎
12. FQDN : Fully Qualified Domain Name ↩︎
13. VUL : VEEAM Universal License ↩︎
14. NTP : Network Time Protocol ↩︎
15. MFA : Multi Factor Authenticator ↩︎
16. VCC : VEEAM Cloud Connect ↩︎
17. OS : Operating System ↩︎
18. TLS : Transport Layer Security ↩︎
19. SGBD : Système de Gestion des Bases de Données ↩︎
20. AGDLP : Account, Global, Domain Local, Permission ↩︎
21. GPO : Group Policy ↩︎
22. SysDBA : Administrateur de Base de Données ↩︎
23. SSO : Single Sign On ↩︎