Revue de sécurité SAP BTP

De nombreuses entreprises font désormais tourner une partie de leur paysage SAP sur SAP Business Technology Platform : launchpads Fiori, applications UI5 et CAP spécifiques, workflows, intégrations vers S/4HANA et vers des services cloud tiers. Ces applications sont souvent construites par des intégrateurs sous contrainte de délai, et la configuration continue de s'étendre après le go-live.

Les revues de sécurité SAP classiques se concentrent sur le back-end S/4HANA : rôles, profils, séparation des tâches. Elles couvrent rarement BTP. Les outils de gestion de la posture de sécurité cloud ne savent généralement pas s'y connecter non plus. Résultat : un subaccount que peu de personnes comprennent entièrement, peu documenté, sans vision claire de qui peut faire quoi, ni de ce qui appelle quoi.

La revue de sécurité BTP répond à deux questions :

Comment un utilisateur s'authentifie-t-il, et quelle identité atteint réellement chaque système derrière l'application ?
Qu'est-ce que l'application appelle réellement, et avec quels identifiants ?

Les réponses reposent sur des preuves collectées sur la plateforme et dans le trafic réel de l'application, pas uniquement sur ce que dit la configuration.

Ce que nous revoyons

Identité et authentification

Trust configuration : quels fournisseurs d'identité sont activés pour la connexion aux applications, et si un chemin non fédéré (comme le SAP ID service par défaut) reste disponible à côté du fournisseur d'identité de l'entreprise
Chaîne de fédération depuis BTP, via SAP Cloud Identity Services (IAS, IPS), jusqu'au fournisseur d'identité de l'entreprise et ses règles d'accès conditionnel
Utilisateurs présents plusieurs fois, sous différents fournisseurs d'identité, avec des droits différents
Création de shadow users et manière dont les utilisateurs métier sont réellement provisionnés

Autorisations sur la plateforme

Role collections, les rôles qu'elles contiennent et leur mode d'attribution : via des groupes ou directement aux utilisateurs
Détenteurs des role collections d'administration (Subaccount Administrator, Destination Administrator, Cloud Connector Administrator et similaires), y compris comptes externes, boîtes aux lettres partagées et comptes sans connexion depuis longtemps
Rôles de workflow et de process automation : si les participants à un processus d'approbation peuvent aussi modifier le workflow ou ses données
Une matrice utilisateurs et rôles couvrant tous les fournisseurs d'identité

Destinations et appels sortants

Chaque destination : cible, type d'authentification, et si c'est l'utilisateur nommé ou un utilisateur technique qui atteint la cible
Mots de passe stockés et identifiants personnels conservés dans les destinations
Appels vers des services cloud externes hors de l'identité d'entreprise et de la gestion des changements
Paramètres faibles comme la validation TLS désactivée, des destinations dynamiques exposées au launchpad, et des destinations obsolètes ou orphelines
Un rapprochement entre destinations configurées et trafic observé : une destination jamais appelée et un appel sans destination correspondante sont tous deux des constats

Exposition du Cloud Connector

Systèmes back-end et ressources exposés au subaccount, et par quels protocoles
Expositions qui ne correspondent pas à la finalité du subaccount, par exemple un système de production accessible depuis un subaccount de développement
Configuration de haute disponibilité et hygiène

Exposition des données applicatives

Inspection des données que l'application reçoit, comparées à ce que l'écran affiche
Détection du schéma où des jeux de données complets sont chargés dans le navigateur et filtrés côté client, de sorte qu'un utilisateur reçoit des données qu'il n'est pas autorisé à voir
Lien entre ce schéma et l'identité utilisée vers le back-end

Plateforme et exploitation

Spaces Cloud Foundry, instances de service et unités applicatives
HANA Cloud : utilisateurs de base de données, privilèges des utilisateurs runtime, liste d'adresses IP autorisées, politiques d'audit
Journalisation d'audit : si les journaux d'audit BTP sont récupérés et transmis à un SIEM
Chemin de transport et de déploiement vers la production, et qui peut l'influencer

Pratiques de développement

Où se trouve le code source, s'il est sous gestion de versions centralisée, et si l'analyse statique de code et la détection de secrets y sont appliquées
Identifiants codés en dur dans le code

Exposition des endpoints

Inventaire des routes et endpoints de service publiés
Vérification de l'accessibilité sans authentification depuis l'intérieur et l'extérieur du réseau de l'entreprise
Revue des paramètres qui gouvernent l'exposition

Il s'agit d'une revue d'exposition et de configuration. Elle n'envoie aucun trafic d'attaque. Les tests d'intrusion et les scans de vulnérabilité sur SAP BTP et RISE nécessitent l'accord écrit préalable de SAP selon ses règles d'engagement. Si un scan est nécessaire, nous vous aidons à en faire la demande auprès de SAP et l'accompagnons dans la fenêtre approuvée.

Notre façon de travailler

Lecture seule. Nous ne modifions aucune configuration, ne lançons pas de « check connection » sur les destinations et n'agissons pas dans les applications métier.
Les preuves d'abord. Captures de trafic navigateur, exports de la plateforme et extractions en ligne de commande sont recoupés entre eux. La configuration seule n'est pas considérée comme la preuve du comportement du système.
Démarrage sans accès à privilèges. La chaîne d'identité et les appels de l'application peuvent être analysés depuis un navigateur et un compte utilisateur standard. L'accès à la plateforme s'ajoute dès qu'il est disponible.
Développement d'abord, production confirmée. Les observations faites sur un subaccount de développement sont présentées comme des observations de conception et confirmées en production avant d'être rapportées comme constats.
Les secrets restent hors du rapport. Les captures sont nettoyées, et les mots de passe ou client secrets stockés ne sont jamais reproduits.

Ce que vous recevez

Un modèle d'identité de l'application, étape par étape, montrant quelle identité atteint chaque système cible
Une cartographie des appels externes et de système à système, avec protocole, authentification et identité pour chacun
Un registre des destinations avec une liste de nettoyage
Une matrice utilisateurs et rôles couvrant tous les fournisseurs d'identité
Une vue d'ensemble de l'exposition du Cloud Connector
Un tableau d'exposition des endpoints
Une liste d'observations avec niveau de risque et étapes de remédiation, rédigée à la fois pour l'équipe applicative et pour l'équipe sécurité

Observations fréquentes

Schémas rencontrés dans des subaccounts BTP, formulés de manière générale :

Le fournisseur d'identité SAP par défaut est toujours activé pour la connexion aux applications à côté du fournisseur d'identité de l'entreprise, ce qui offre un chemin qui contourne la fédération, le MFA et l'accès conditionnel
Le back-end est atteint avec un utilisateur technique et un mot de passe stocké, de sorte que les autorisations back-end s'appliquent à l'utilisateur technique et non à la personne qui utilise l'application
Les applications chargent des jeux de données complets dans le navigateur et les filtrent côté client
Des role collections d'administration sont attribuées directement à de nombreux utilisateurs, souvent externes et souvent inactifs
Des identifiants personnels de consultants actuels ou passés restent stockés dans des destinations
Des intégrations sortantes reposent sur des comptes hors de l'identité d'entreprise
Un ancien moteur de workflow et ses rôles d'administration subsistent après la migration vers un service plus récent
Aucune récupération des journaux d'audit BTP

Pour qui

Les entreprises qui exploitent des applications ou workflows spécifiques sur SAP BTP et ont besoin d'une vision claire de leur fonctionnement
Les équipes sécurité sans visibilité sur BTP, avant ou en complément d'un outil de surveillance continue
Les entreprises qui ont migré S/4HANA vers RISE et veulent vérifier que la partie BTP respecte l'architecture prévue

La revue complète nos services de sécurité S/4HANA et GRC, qui couvrent le modèle d'autorisation du back-end. Pour le contexte sur les contrôles concernés, voir notre guide de la sécurité SAP BTP.

Parlons d'une revue

Contactez-nous pour discuter de votre paysage BTP et du périmètre d'une revue.

Nous contacter