Bonnes pratiques en matière de sécurité IAM - AWS SDK pour SAP ABAP
Bonnes pratiques pour le profil d'instance Amazon EC2Rôles IAM pour les utilisateurs de SAPConsidérations relatives à la sécurité du profil source

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Bonnes pratiques en matière de sécurité IAM

L'administrateur IAM sera responsable des trois domaines clés suivants.

  • Veiller à ce que le système SAP puisse s'authentifier à l'aide des métadonnées Amazon EC2 ou des informations d'identification par clé secrète.

  • Veiller à ce que le système SAP dispose des autorisations dont il a besoin pour s'améliorer. sts:assumeRole

  • Pour chaque rôle IAM logique, création d'un rôle IAM pour les utilisateurs SAP disposant des autorisations requises pour exécuter les fonctions commerciales (par exemple, les autorisations nécessaires pour Amazon S3, DynamoDB ou d'autres services). Ce sont les rôles que les utilisateurs de SAP assumeront.

Pour plus d'informations, consultez le chapitre sur la sécurité dans SAP Lens : AWS Well-Architected Framework.

Bonnes pratiques pour le profil d'instance Amazon EC2

L'instance Amazon EC2 sur laquelle votre système SAP s'exécute dispose d'un ensemble d'autorisations basé sur son profil d'instance. En général, le profil d'instance doit uniquement disposer des autorisations d'appelsts:assumeRole, afin de permettre au système SAP d'assumer des rôles IAM spécifiques à l'entreprise selon les besoins. Cette élévation vers d'autres rôles garantit qu'un programme ABAP peut assumer un rôle qui donne à l'utilisateur le moins de privilèges nécessaires pour faire son travail. Par exemple, un profil d'instance peut contenir l'instruction suivante.

JSON

{
 "Version":"2012-10-17",		 	 	 
 "Statement": [
   {
     "Sid": "VisualEditor0",
     "Effect": "Allow",
     "Action": "sts:AssumeRole",
     "Resource":[
        "arn:aws:iam::012345678912:role/finance-cfo",
        "arn:aws:iam::012345678912:role/finance-auditor",
        "arn:aws:iam::012345678912:role/finance-reporting"
      ]
   }
 ]
}

Cet exemple précédent permet au système SAP d'assumer les rôles IAM pour l'utilisateur CFO, AUDITOR ou REPORTING. AWS Le SDK choisira le rôle IAM approprié pour l'utilisateur en fonction du rôle PFCG de l'utilisateur dans SAP.

Le profil d'instance Amazon EC2 peut également être utilisé pour d'autres fonctions.

Ces solutions peuvent également nécessiter des sts:assumeRole autorisations pour des rôles spécifiques à la sauvegarde ou au basculement, ou elles peuvent nécessiter l'attribution d'autorisations directement au profil d'instance.

Rôles IAM pour les utilisateurs de SAP

Le programme ABAP a besoin d'autorisations pour effectuer le travail de l'utilisateur : lire une table DynamoDB, invoquer Amazon Textract sur un objet PDF dans Amazon S3, exécuter une fonction. AWS Lambda Le même modèle de sécurité est utilisé dans tous les cas AWS SDKs. Vous pouvez utiliser un rôle IAM existant qui a été utilisé pour un autre AWS SDK.

L'analyste commercial SAP demandera à l'administrateur IAM le arn:aws : d'un rôle IAM pour chaque rôle logique nécessaire. Par exemple, dans un scénario financier, l'analyste commercial peut définir les rôles IAM logiques suivants.

  • CFO

  • AUDITOR

  • REPORTING

L'administrateur IAM définira les rôles IAM pour chaque rôle IAM logique.

CFO

  • arn:aws:iam::0123456789:role/finance-cfo

  • autorisations de lecture et d'écriture sur un compartiment Amazon S3

  • autorisations de lecture et d'écriture sur une base de données DynamoDB

AUDITOR

  • arn:aws:iam::0123456789:role/finance-auditor

  • autorisations de lecture pour un compartiment Amazon S3

  • autorisations de lecture sur une base de données DynamoDB

REPORTING

  • arn:aws:iam::0123456789:role/finance-reporting

  • autorisations de lecture sur une base de données DynamoDB

  • aucune autorisation pour le compartiment Amazon S3

L'analyste commercial saisira les rôles IAM dans une table de mappage pour mapper les rôles IAM logiques avec les rôles IAM physiques.

Les rôles IAM pour les utilisateurs SAP doivent autoriser l'sts:assumeRoleaction pour les principaux fiables. Les principes fiables peuvent varier en fonction de la manière dont le système SAP est authentifié. AWS Pour plus de détails, consultez la section Spécification d'un principal.

Voici quelques exemples des scénarios SAP les plus courants.

  • Système SAP exécuté sur Amazon EC2 avec un profil d'instance attribué. Dans ce cas, un profil d'instance Amazon EC2 est associé à un rôle IAM.

    JSON
    {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole"
            ],
            "Principal": { 
                "AWS": "arn:aws:iam::123456789012:role/SapInstanceProfile" 
            }
        }
    ]
}

  • Systèmes SAP exécutés sur Amazon EC2 sans profil d'instance. Dans ce cas, Amazon EC2 assume des rôles pour les utilisateurs SAP.

    JSON
    {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole"
            ],
            "Principal": { 
                "Service": [ "ec2.amazonaws.com" ] 
            }
        }
    ]
}

  • Systèmes SAP exécutés sur site : les systèmes SAP exécutés sur site ne peuvent s'authentifier qu'à l'aide de la clé d'accès secrète. Pour plus d'informations, consultez la section Authentification du système SAP activée AWS.

    Ici, tout rôle IAM assumé par un utilisateur SAP doit avoir une relation de confiance qui fait confiance à l'utilisateur SAP.

    JSON
    {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole"
            ],
            "Principal": { 
                "AWS": "arn:aws:iam::123456789012:user/SAP_SYSTEM_S4H" 
            }
        }
    ]
}

Considérations relatives à la sécurité du profil source

Lors de l'utilisation du profil source :

Gestion des rôles IAM

Critique : les rôles IAM dans les chaînes de profils sources doivent être gérés de manière stricte pour empêcher tout accès non autorisé et toute augmentation de privilèges :

  • Appliquer le principe du moindre privilège : accordez uniquement les autorisations minimales requises pour l'objectif spécifique de chaque rôle

  • Auditez régulièrement les autorisations des rôles : passez en revue et mettez à jour les politiques relatives aux rôles tous les trimestres ou lorsque les exigences changent

  • Surveiller l'utilisation des rôles : à utiliser pour suivre les appels AssumeRole d'API et identifier les modèles inhabituels

  • Limitez les relations de confiance : limitez les principaux autorisés à assumer chaque rôle uniquement à ceux qui ont absolument besoin d'un accès

  • Utilisez des conditions dans les politiques de confiance : ajoutez des conditions telles que l'adresse IP source, les exigences en matière de MFA ou des restrictions temporelles, le cas échéant

  • Documenter les objectifs des rôles : conservez une documentation claire sur le cas d'utilisation prévu pour chaque rôle et les autorisations requises

Autorisation et contrôle d'accès

  • Assurez-vous que les politiques de confiance appropriées sont configurées pour tous les profils intermédiaires de la chaîne

  • Les utilisateurs doivent avoir /AWS1/SESS une autorisation pour TOUS les profils de la chaîne, y compris les profils intermédiaires

  • Chaque rôle IAM doit explicitement faire confiance au rôle précédent dans la chaîne

Garanties techniques

  • Le SDK impose une profondeur de chaîne maximale de 5 profils afin d'éviter les appels d'API STS excessifs

  • Les références circulaires sont automatiquement détectées et bloquées

  • La méthode d'authentification du profil de base est validée pour garantir qu'elle utilise une méthode standard (INST, SSF ou RLA)

Pour plus d'informations sur la configuration du profil source, voir Utilisation du profil source pour l'accès entre comptes.