Liste de contrôle : examen de l'architecture et de la conception

Votre schéma de conception identifie et comprend la stratégie de sécurité de l'entreprise, et s'y adapte.

Les restrictions imposées par la sécurité de l'infrastructure (y compris les restrictions des services, protocoles et pare-feu) sont identifiées.

Votre schéma de conception reconnaît les restrictions imposées par les environnements d'hébergement (y compris les exigences d'isolement de l'application) et s'y adapte.

Le niveau de confiance de la sécurité d'accès au code de l'environnement cible est connu.

Votre schéma de conception identifie les exigences de l'infrastructure de déploiement et la configuration de déploiement de l'application.

Les structures de domaine, les serveurs d'application distants et les serveurs de base de données sont identifiés.

Votre schéma de conception identifie les exigences de clustering.

Votre schéma de conception identifie les points de maintenance de la configuration de l'application (tels que ce qui doit être configuré et quels sont les outils disponibles pour un admin IDC).

Les fonctions de communication sécurisées offertes par la plate-forme et l'application sont connues.

Votre schéma de conception tient compte des problèmes associés aux batteries de serveurs Web (y compris la gestion de l'état, les clés de cryptage en fonction des machines, Secure Sockets Layer (SSL), les questions de déploiement de certificat et les profils itinérants).

Votre schéma de conception identifie l'autorité de certification (CA) devant être utilisée par le site afin de prendre en charge SSL.

Votre schéma de conception répond aux critères requis en matières d'évolutivité et de performances.

Votre schéma de conception identifie tous les points d'entrée et limites sécurisées.

La validation des entrées est appliquée chaque fois que des données entrées sont reçues de l'extérieur de la limite sécurisée actuelle.

Votre schéma de conception part du principe que toute saisie est malveillante.

La validation centralisée de la saisie est utilisée si nécessaire.

La stratégie de validation de la saisie adoptée par l'application est modulaire et cohérente.

L'approche de validation est de contraindre, rejeter et assainir la saisie. (Il est plus facile de rechercher une saisie connue, valide et saine que de rechercher une saisie que l'on sait malveillante ou dangereuse).

Les données sont validées par type, longueur, format et plage de données.

Votre schéma de conception répond aux problèmes que peuvent poser les noms canoniques.

La saisie des noms de fichiers et des chemins d'accès aux fichiers est évitée autant que possible.

Votre schéma de conception répond aux problèmes potentiels d'injection SQL.

Votre schéma de conception répond aux problèmes potentiels de scripts inter-site.

Votre schéma de conception ne se fie pas à la validation côté client.

Votre schéma de conception applique à la validation de la saisie la stratégie de défense renforcée par la validation de la saisie à travers les niveaux.

Le résultat contenant la saisie est codé avec HtmlEncode et UrltEncode.

Les limites sécurisées de l'application sont identifiées par la conception.

Votre schéma de conception identifie les identités utilisées pour accéder aux ressources à travers les limites sécurisées.

Votre schéma de conception partitionne le site Web en zones publique et restreinte en utilisant des dossiers distincts.

Votre schéma de conception identifie les exigences de compte de service.

Votre schéma de conception identifie le stockage sécurisé des informations d'identification acceptées par les utilisateurs.

Votre schéma de conception identifie les mécanismes de protection des informations d'identification sur le réseau (SSL, IPSec, cryptage, etc.).

Les stratégies de gestion des comptes sont prises en considération par la conception.

Votre schéma de conception assure que le minimum d'informations d'erreur est retourné en cas d'échec de l'authentification.

Votre schéma de conception identifie l'identité utilisée pour l'authentification auprès de la base de données.

Si l'authentification SQL est utilisée, les informations d'identification sont correctement sécurisées sur le réseau (SSL ou IPSec) et dans le stockage (DPAPI).

Votre schéma de conception adopte une stratégie d'utilisation des comptes les moins privilégiés.

Les résumés des mots de passe (avec salt) sont stockés dans le magasin d'utilisateurs pour vérification.

Des mots de passe sûrs sont utilisés.

Les tickets d'authentification (cookies) ne sont pas transmis sur des connexions non cryptées.

Les rôles prévus dans la conception offrent une séparation suffisante des privilèges (le degré de détail requis en matière d'autorisation est pris en compte).

Plusieurs gardes-barrières sont utilisés pour une défense renforcée.

Le nom de connexion de l'application à la base de données est limité et ne peut accéder qu'aux procédures stockées sélectionnées.

Le nom de connexion de l'application ne dispose pas des autorisations permettant d'accéder directement aux tables.

L'accès aux ressources de niveau système est restreint.

Votre schéma de conception identifie les exigences de sécurité d'accès au code. Les ressources privilégiées et opérations privilégiées sont identifiées.

Toutes les identités utilisées par l'application sont identifiées et les ressources auxquelles accède chaque identité sont connues.

Les interfaces d'administration sont sécurisées (l'authentification et l'autorisation renforcées sont utilisées).

Les canaux d'administration distants sont sécurisés.

Les configurations stockées sont sécurisées.

Les secrets de configuration ne sont pas conservés en clair dans les fichiers de configuration.

Les privilèges d'administrateur sont séparés en fonction des rôles (par exemple, développeur du contenu d'un site ou administrateur système).

Des comptes de processus et des comptes de service les moins privilégiés sont utilisés.

Les secrets ne sont pas stockés sauf si nécessaire. (D'autres méthodes ont été explorées à la phase de conception.)

Les secrets ne sont pas stockés dans le code.

Les connexions à la base de données, les mots de passe, les clés et autres secrets ne sont pas stockés en clair.

Votre schéma de conception identifie la méthodologie de stockage sécurisé des secrets. (Des algorithmes et des tailles de clés appropriés sont utilisés pour le cryptage. Il est préférable que DPAPI soit utilisé pour stocker les données de configuration, afin d'éviter la gestion des clés.)

Les données sensibles ne sont pas consignées en clair par l'application.

Votre schéma de conception identifie les mécanismes de protection des données sensibles envoyées sur le réseau.

Les données sensibles ne sont pas stockées dans des cookies persistants.

Les données sensibles ne sont pas transmises en utilisant le protocole GET.

SSL est utilisé pour protéger les cookies d'authentification.

Le contenu des cookies d'authentification est crypté.

La durée de vie d'une session est limitée.

L'état d'une session est protégé des accès non autorisés.

Les identificateurs de session ne sont pas transmis dans des chaînes de requête.

La cryptographie au niveau de la plate-forme est utilisée et n'a pas d'implémentations personnalisées.

Votre schéma de conception identifie l'algorithme de cryptographie correct (ainsi que la taille de clé) correspondant aux besoins de cryptage des données de l'application.

La méthodologie permettant de sécuriser les clés de cryptage est identifiée.

Votre schéma de conception identifie la stratégie de recyclage des clés de l'application.

Les clés de cryptage sont sécurisées.

DPAPI est utilisé autant que possible pour éviter les problèmes de gestion de clé.

Les clés sont recyclées périodiquement.

Tous les paramètres de saisie sont validés (y compris les champs de formulaires, les chaînes de requête, les cookies et les en-têtes HTTP).

Les cookies contenant des données sensibles sont cryptés.

Les données sensibles ne sont pas transmises dans des chaînes de requête ou des champs de formulaire.

Les informations d'en-tête HTTP ne servent pas à prendre des décisions de sécurité.

L'état d'affichage est protégé à l'aide de MACs.

Votre schéma de conception met l'accent sur une approche standardisée de la gestion structurée des exceptions à travers l'application.

La gestion des exceptions de l'application réduit la divulgation des informations en cas d'exception.

Votre schéma de conception identifie les messages d'erreur génériques retournés au client.

Les erreurs de l'application sont consignées dans un journal d'erreurs.

Les données privées (par exemple, les mots de passe) ne sont pas consignées.

Votre schéma de conception identifie le niveau d'audit et de journalisation nécessaires pour l'application, ainsi que les paramètres principaux à consigner et à analyser.

Votre schéma de conception prend en considération la manière de faire circuler l'identité de l'appelant à travers plusieurs couches (au niveau du système d'exploitation ou de l'application) pour l'audit.

Votre schéma de conception identifie le stockage, la sécurité et l'analyse des fichiers journaux de l'application.