Stocker en toute sécurité les informations d'identification de l'API qui doivent être utilisées en texte brut

Question

J'ai créé une application qui sert de pont entre deux API différentes - WebEx & Exchange Web Services - et Email. Un utilisateur envoie une invitation de calendrier à une adresse e-mail spéciale, l'application analyse le SCI et crée une réunion WebEx, puis se connecte aux services Web Exchange et place les informations d'invitation WebEx dans l'invitation d'origine.

Ceci a été créé car WebEx n'a pas d'intégration Mac Email/Calendrier. L'inconvénient est que pour utiliser API WebEx et l'API Exchange, j'ai évidemment besoin d'informations d'identification pour les deux API. Je stocke en toute sécurité les informations d'identification avec le chiffrement AES 256 bits dans la base de données, mais pour accéder aux API, j'ai besoin d'informations d'identification en texte brut (pas de support oAuth ou token dans les API). Ils sont bien sûr transmis via SSL, bien sûr.

Le risque de sécurité n'est pas d'avoir volé les mots de passe car les clés de chiffrement sont stockées en toute sécurité. Le problème que je cherche à résoudre est le fait que les clients craignent que leurs informations d'identification d'entreprise soient stockées de manière à permettre à quelqu'un ayant accès à ces clés - moi ou quelqu'un de l'équipe de développement - de déchiffrer leurs informations et accéder aux informations d'identification. .

La valeur de l'application est grande - elle économise du temps, mais comment puis-je me protéger contre cette peur, tout en permettant à cette approche de fonctionner?

Answer 1

En réalité, si votre code doit envoyer les mots de passe, alors si un développeur a le code source et les mots de passe cryptés, ils auront accès aux mots de passe de test simples. Le seul moyen de contourner ce problème est de refuser à l'équipe de développement l'accès aux mots de passe cryptés et de refuser l'accès au code source aux personnes ayant un mot de passe crypté. Vous accomplissez cela en éloignant l'équipe de développement de la base de données de production.

Le risque de sécurité est que vous avez accès à la base de données de production stockant les clés. Éliminer cet accès et leur préoccupation devrait être éliminée. Fournissez un utilitaire (basé sur le bureau ou sur le Web) qui peut être utilisé pour configurer les clés - une bonne idée de toute façon puisque ces mots de passe devront être changés dans le futur.

Demandez au client de créer une base de données, puis de pointer l'application vers la base de données via un changement de chaîne de connexion. Le client peut utiliser l'utilitaire pour définir les mots de passe.