Contrôle d'accès
Pour les organisations qui adoptent une stratégie reposant sur un environnement hébergé dans le cloud, le contrôle d'accès représente l'un des défis les plus importants à relever. Les locataires doivent avoir l'assurance que les informations stockées dans les infrastructures partagées sont protégées et accessibles aux seuls hôtes, services, utilisateurs, groupes et rôles autorisés. Les hôtes, les utilisateurs et les services doivent être soumis à des contraintes supplémentaires, conformément au principe du moindre privilège, selon lequel les droits et les autorisations ne sont attribués que pour exécuter une opération donnée.
Le système SuperCluster facilite la mise en place d'une architecture de contrôle d'accès organisée en couches et offrant une grande souplesse. Elle couvre chaque niveau de la pile et remplit différents rôles, notamment utilisateur final, administrateur de base de données et administrateur système. Les organisations peuvent ainsi définir des stratégies qui protègent les hôtes, les applications et les bases de données de manière individuelle et protéger les infrastructures de calcul, de stockage et réseau sous-jacentes sur lesquelles ces services sont exécutés.
Au niveau de la couche de virtualisation et du système d'exploitation, le contrôle d'accès commence par la réduction du nombre de services exposés sur le réseau. Cela facilite le contrôle de l'accès aux consoles, domaines et zones Oracle VM Server for SPARC. En diminuant le nombre de points d'entrée par le biais desquels les systèmes sont accessibles, il est également possible de réduire le nombre de stratégies de contrôle d'accès et leur complexité pendant la durée de vie du système.
Dans le système d'exploitation Oracle Solaris, les contrôles d'accès sont implémentés en combinant des autorisations POSIX avec l'utilitaire de contrôle d'accès basé sur les rôles (RBAC) d'Oracle Solaris. La capacité de pouvoir protéger des attaques réseau les hôtes, les applications, les bases de données et les services connexes exécutés sur le système SuperCluster est tout aussi importante. Pour y parvenir, les locataires doivent d'abord vérifier que seuls les services réseau autorisés sont exécutés et à l'écoute des connexions réseau entrantes. Lorsque la surface exposée aux attaques réseau a été minimisée, les locataires peuvent configurer le reste des services pour qu'ils écoutent les connexions entrantes uniquement sur des réseaux et des interfaces autorisés. Cette simple précaution permet de garantir que les protocoles de gestion, tels que le shell sécurisé (SSH), sont inaccessibles sauf depuis le réseau de gestion.
Figure 6 Récapitulatif du contrôle d'accès de bout en bout
Par ailleurs, les locataires peuvent aussi choisir d'implémenter un pare-feu basé sur un hôte, tel que le service IP Filter d'Oracle Solaris. Les pare-feu basés sur un hôte sont utiles car ils fournissent des hôtes dotés d'un plus grand nombre de fonctionnalités pour contrôler l'accès aux services réseau. Par exemple, IP Filter permet le filtrage de paquets avec état et est capable de filtrer les paquets en fonction de leur adresse IP, du port, du protocole, de l'interface réseau et de la direction du trafic. Ces fonctionnalités sont importantes pour certaines plates-formes comme SuperCluster qui gèrent de nombreuses interfaces réseau et prennent en charge diverses communications réseau entrantes et sortantes.
Sur le système SuperCluster, le service IP Filter peut être configuré dans un domaine Oracle VM Server for SPARC ou géré depuis une zone Oracle Solaris. La stratégie de contrôle d'accès réseau peut donc être appliquée depuis le conteneur du système d'exploitation dans lequel les services de base de données sont offerts. Dans un scénario multilocataire, le volume d'activités réseau entrantes sera probablement minimal et pourra être facilement catégorisé de manière à créer une stratégie qui limite les communications à des interfaces et des destinations réseau spécifiques. Tout autre trafic est refusé et consigné, dans le cadre d'une stratégie de “refus par défaut” destinée à bloquer les communications non autorisées, tant entrantes que sortantes.
La sécurité de l'utilisateur final d'Oracle permet aux locataires d'intégrer leurs applications et bases de données à leurs services de gestion d'identité existants pour prendre en charge le service SSO (Single Sign-On, connexion unique) et la gestion centralisée des utilisateurs et des rôles. En particulier, la sécurité de l'utilisateur final d'Oracle permet de centraliser (1) le provisionnement et le déprovisionnement des utilisateurs et des administrateurs de base de données, (2) la gestion des mots de passe et la réinitialisation des mots de passe en libre-service et (3) la gestion des autorisations à l'aide de rôles de base de données globaux. Les organisations qui requièrent des méthodes d'authentification mutifacteur, telles que Kerberos ou PKI, peuvent tirer parti d'Oracle Advanced Security.
La technologie Oracle Exadata Storage Server prend en charge un ensemble prédéfini de comptes utilisateur, chacun doté de ses propres privilèges. Les administrateurs qui exécutent des tâches d'administration Oracle Exadata Storage Server doivent utiliser un de ces rôles prédéfinis pour accéder au système. L'appareil de stockage ZFS, quant à lui, prend en charge la création de comptes d'administration locaux et distants, tous deux capables d'assurer l'attribution individuelle de rôles et de privilèges.
Par défaut, les serveurs Oracle Exadata Storage Server utilisés dans le système SuperCluster sont accessibles aux domaines de base de données qui utilisent l'utilitaire Oracle Automatic Storage Management. Cet utilitaire permet aux fournisseurs de cloud de créer des groupes de disques distincts pour chaque locataire capables de répondre à leurs besoins en termes de capacité, performance et disponibilité. Oracle Automatic Storage Management prend en charge trois modes de contrôle d'accès : la sécurité ouverte, la sécurité basée sur Oracle Automatic Storage Management et la sécurité au niveau base de données.
Dans un scénario multilocataire, la sécurité basée sur les bases de données est recommandée, car elle procure le plus haut niveau de précision en matière de contrôle d'accès. Dans ce mode, il est possible de configurer des groupes de disques de manière à ce qu'ils soient accessibles à une seule base de données. En particulier, cela signifie qu'il est possible de restreindre l'accès des administrateurs et des utilisateurs de base de données aux disques de grille qui contiennent des informations pour lesquelles ils disposent de privilèges. Dans les scénarios de consolidation de bases de données dans lesquels une même base peut prendre en charge plusieurs organisations ou locataires, il est important que chaque locataire ne puisse ouvrir et manipuler que ses propres données. En particulier, en associant les stratégies d'isolement de charge de travail et de base de données, les locataires sont en mesure de cloisonner efficacement l'accès à chaque base de données.
La sécurité basée sur les bases de données est un outil efficace pour limiter l'accès aux disques de grille Oracle ASM. La figure suivante présente une architecture combinant la sécurité basée sur Oracle ASM et la sécurité ZFS. Lorsqu'un grand nombre d'instances Oracle Database sont déployées sur la plate-forme SuperCluster, il est sans doute plus pertinent d'appliquer une stratégie de sécurité basée sur Oracle ASM et applicable à chaque locataire, car elle réduit considérablement le nombre de clés devant être créées, assignées et gérées. De plus, comme la sécurité basée sur les bases de données requiert la création de groupes de disques séparés pour chaque base de données, cette méthode permet également de diminuer de manière significative le nombre de disques de grille devant être créés sur un serveur Exadata Storage Server.
Figure 7 Sécurité basée sur Oracle ASM par locataire
Le système SuperCluster utilise la protection des liaisons de données d'Oracle Solaris, dont l'objectif est d'éviter les dommages causés au réseau par les machines virtuelles de locataires malveillants. Cette fonctionnalité Oracle Solaris intégrée offre une protection contre les menaces de base suivantes : les usurpations d'adresse IP et MAC et de cadre L2 (par exemple, les attaques au niveau des BPDU [Bridge Protocol Data Unit]). La protection des liaisons de données d'Oracle Solaris doit être appliquée de manière individuelle à toutes les zones Oracle Solaris non globales déployées dans l'environnement multilocataire.
Comme les locataires, à titre individuel, ne devraient jamais disposer de droits au niveau administratif ou hôte pour accéder aux serveurs Exadata Storage Server, il est vivement conseillé de restreindre ce type d'accès. Les serveurs Exadata Storage Server doivent être configurés pour bloquer l'accès direct aux domaines d'E/S de base de données et aux zones non globales de locataires tout en permettant l'accès à partir des domaines de base de données SuperCluster (gérés par le fournisseur de cloud). Les serveurs Exadata Storage Server sont ainsi seulement gérés à partir d'emplacements approuvés sur le réseau de gestion.
Lorsque la configuration de la sécurité des locataires a été définie et implémentée, les fournisseurs de services peuvent passer à l'étape supplémentaire qui consiste à configurer des zones globales et non globales spécifiques aux locataires en tant qu'environnements immuables en lecture seule. Les zones immuables créent une environnement d'exploitation présentant un haut niveau de résistance et d'intégrité dans lequel les locataires peuvent exécuter leurs propres services. En tirant parti des fonctionnalités de sécurité inhérentes à Oracle Solaris, les zones immuables permettent de garantir qu'une partie (ou la totalité) des répertoires et des fichiers du système d'exploitation ne pourra pas être modifiée sans l'intervention du fournisseur de services cloud. La mise en oeuvre de cette approche en lecture seule permet d'empêcher les modifications non autorisées, de promouvoir des procédures de gestion des modifications plus robustes et d'empêcher l'introduction de programmes malveillants via le noyau ou l'utilisateur.