Considérations relatives à la sécurité - site Web/portail sur GAE

Question

Si vous devez créer un site Web de bureau (qui sert de plate-forme pour les clients/clients/employés) pour vous connecter et accéder aux données partagées, quelles sont les considérations de sécurité. Le portail de bureau a été développé en django/python et hébergé par GAE. Essentiellement, le point final est livré avec un identifiant/mot de passe pour entrer dans le portail et accéder aux données.

Je voudrais savoir: a) que pouvons-nous faire pour assurer un niveau de sécurité élevé? Essentiellement, les données sont essentielles et doivent donc être consultées uniquement par des personnes autorisées. Donc, je voudrais faire en sorte que "L'application est aussi sûre que - comment on garde son mot de passe en toute sécurité.", La seule façon d'entrer dans le système (non autorisé) est par une fuite de mot de passe (par la personne) façon." :) b) pouvons-nous héberger les applications sur GAE (appspot.com) avec https? c) existe-t-il de meilleurs moyens de sécuriser d'autres mots de passe (j'ai entendu parler des clés/certificats ssh). Mais les utilisateurs finaux ne sont peut-être pas très avertis.

Answer 1

Il y a toujours le choix entre usabiity et secutity. Plus vous implémentez de fonctionnalités de sécurité, plus il devient difficile de l'utiliser.

pouvons-nous héberger les applications sur GAE (appspot.com) avec https?

Oui, mais pas sur votre propre domaine, uniquement sur appspot.com. Si vous diffusez votre application hors de son propre domaine, vous devez diriger tout le trafic sécurisé via le domaine appspot de votre application (sur votre propre domaine, vous devez acheter un certificat SSL et disposer d'une adresse IP dédiée, etc.). Si vous en avez vraiment besoin, il existe des moyens de router le trafic SSL sur votre propre domaine, mais comme cela nécessite un autre serveur exécutant quelque chose comme stunnel, cela donne aux attaquants une autre cible d'attaque. Si votre application dispose d'une authentification par nom d'utilisateur/mot de passe, l'application est vraiment aussi sûre que si vous gardez son mot de passe en toute sécurité, si vous n'avez aucun bogue dans votre code qui pourrait être exploité. A propos du "hackish way": sur GAE, vous n'avez pas à vous soucier de la sécurité du serveur, la seule cible d'attaque possible est votre code.

Voici quelques-unes des stratégies pour la sécurisation de votre application:

• bonne QA et revue de code pour trouver des bogues critiques; Django a déjà une protection intégrée contre la plupart des attaques triviales comme XSRF et l'injection SQL, alors regardez les parties de votre propre code qui sont liées aux données critiques et à l'authentification
• pensez à d'autres méthodes d'authentification comme les certificats côté client (facile à utiliser pour l'utilisateur final, la plupart des navigateurs prennent en charge ce système d'exploitation natif et moderne, ce qui n'est probablement pas facile sur GAE)
• le point le plus faible de tout environnement sécurisé est l'utilisateur, vous devez donc informer les utilisateurs Bonnes pratiques de manipulation des données sensibles et des mots de passe (BTW, nécessitant un changement de mot de passe tous les quelques mois n'améliore pas la sécurité car les utilisateurs écrivent leurs mots de passe car ils ne peuvent s'en souvenir, vous perdez plus de sécurité que vous n'en gagnez)
• vous devriez avoir une bonne détection d'intrusion pour verrouiller un attaquant dès que possible, comme exemple d'analyse du comportement; Exemple: si un utilisateur des USA se connecte à partir d'une adresse IP en Estonie, ceci est suspect
• restrictions d'accès réseau: vous pouvez bloquer toutes les plages IP sauf celles de votre entreprise d'accès aux données critiques, si un mot de passe est divulgué, cela minimise l'impact possible
• améliorer la sécurité de l'utilisateur final: si l'un des utilisateurs a un cheval de Troie sur son ordinateur qui effectue des captures d'écran ou des keylogs, toute votre sécurité est perdue car l'attaquant peut simplement regarder l'utilisateur pendant qu'il regarde des données sensibles; vous devriez avoir une bonne police de la sécurité dans votre entreprise
• forcent les utilisateurs à accéder à votre site via SSL, vous ne devriez pas laisser les utilisateurs choisir s'ils préfèrent la sécurité ocer confort de ne pas