Se conformer aux exigences de protection des données sans trop en dévoiler?
Je suis entrepreneur pour quelques entreprises. Je construis et héberge leurs systèmes sur des serveurs que je loue auprès d'un hôte international populaire. Je stocke le code système sur un système de contrôle de version populaire hébergé à l'international. Il existe un mélange de techniques d'authentification à différents points, la plupart d'entre elles étant des pratiques presque optimales.
Cependant, je couche également sur une certaine obscurité. SSH est caché, certaines choses sont cryptées de manière non évidente. Seuls ceux-ci ne seraient pas précieux mais à côté de la sécurité réelle, je repousse les menaces les plus sérieuses.
Un de mes clients a reçu une demande de processus de protection des données d'un de leurs clients aujourd'hui: une énorme organisation gouvernementale. Ils prennent évidemment ces trucs bureaucratiques très au sérieux et nous ont envoyé un long questionnaire qui demande des détails de sécurité spécifiques . Pas seulement sur les données que nous collectons, mais aussi où elles sont sécurisées, comment elles sont sécurisées, où se trouvent les verrous et qui a les clés.
Les dernières de ces choses sont le genre de choses que je cache à mes clients, sans parler des leurs. En tant que personne avec toutes les clés, je suis très conscient de cette bande dessinée galvaudée mais précise:
Actuellement, les clients de mes clients ne me connaissent pas. Pas vraiment. Mais si nous donnons suite à leur demande, toute personne ayant accès à cette demande sait soudain qui je suis, où je suis, à quoi j'ai accès. Si vous vouliez pénétrer dans leur partie de ce système, vous venez après moi.
Et vous pouvez aller plus loin. Une partie de cette demande mentionne les stratégies de contrôle d'accès et donne un exemple qui explique où (exactement, géographiquement) une clé privée est stockée. Si vous suivez cela à travers chaque système qui touche tangentiellement les données qu'ils soumettent, ils ont une carte de chaque système que nous utilisons et savent à qui s'adresser (ou pirater) pour avoir accès à tout. Cela me dérange.
Ma question est, selon votre expérience, existe-t-il un moyen de se conformer aux demandes de procédure de sécurité qui ne cible pas des personnes, des ordinateurs ou même des ports spécifiques?
Très peu de ces choses sont une exigence légale réelle. Nous respectons déjà les directives de la loi sur la protection des données ... Mais encore une fois, étant une grande agence gouvernementale, leur volonté de cocher des cases semble supérieure à toute autre organisation.
Juste quelques clarifications.
Mon le client a des détails sur le système. Ils n'ont pas d'accès direct aux opérations du serveur. Ils ont accès au système de contrôle de version et reçoivent des sauvegardes de données chiffrées très régulièrement et ont un document (et des clés de chiffrement) qui explique comment remplacer le système que j'exécute par l'un des leurs en cas de disparition prématurée. Nous avons discuté de la vue d'ensemble, mais les détails exacts sont sous clé et clé physique.
Nous ne traitons pas des codes de lancement. Noms, coordonnées et adresses IP. Je ne m'attendais pas à ce que cela soit pertinent pour la question, mais les gens évoquent la règle des deux hommes. C'est façon sur le dessus ici. C'est techniquement sous-PCI-DSS.
Je suis développeur et opérations pour cette petite entreprise (ainsi que pour d'autres). Beaucoup d'entre vous disent que je suis le point faible. Je suis. Une clé et vous avez les données que j'ai. Voilà pourquoi je demande.
S'il vous plaît, plutôt que de simplement le signaler, certaines suggestions sur ce qu'il faut faire à propos de ces choses à petite échelle seraient plus utiles. Je ne peux pas être le seul devop de la planète à traiter tangentiellement avec les gouvernements.
La demande de ces informations peut concerner non seulement un audit de sécurité, mais également un audit de processus, et il semble que cela puisse être fondé, car:
Si vous vouliez pénétrer dans leur partie de ce système, vous venez après moi.
Que se passerait-il si vous étiez "heurté par un camion" demain? Si vous êtes le seul à connaître les systèmes, vos clients et les leurs auraient certainement un gros problème. Idéalement, une autre personne doit également avoir accès, et il doit être documenté qui c'est et comment le contacter.
Selon les exigences, il peut être possible que le détenteur des clés soit une entreprise plutôt qu'une personne, peut-être avec un contact principal et secondaire nommé. Le contact principal pourrait également être quelqu'un chez votre client, et il devrait probablement avoir toute la documentation pour savoir comment accéder à ses systèmes en cas d'urgence si vous n'êtes pas disponible.
De plus, vous pourrez peut-être fournir un rapport avec certaines choses expurgées. Ils sont probablement plus intéressés à savoir que la documentation non caviardée existe quelque part et que les bonnes personnes y ont accès en cas de besoin. Ils ne se soucieront probablement pas que les numéros de port, etc. soient masqués, tant qu'ils peuvent être sûrs qu'ils existent quelque part dans un document.
Vous avez dit que "très peu de ces choses sont une exigence légale réelle", mais selon le gouvernement concerné, cela peut être une exigence légale très stricte. Si ce gouvernement exige que leurs ministères/agences suivent NIST SP800-5 alors ils ne peuvent pas simplement répondre "nous avons un gars". Les réponses à ces contrôles de sécurité nécessitent des informations détaillées indiquant qui, quoi, où, quand, pourquoi et comment. Le fait de ne pas fournir ces informations peut empêcher cette entité gouvernementale de recevoir l'autorisation d'exploiter ce système d'information. Par conséquent, vous pouvez vous attendre à devoir faire savoir à cette entité gouvernementale qui vous êtes et quels sont vos processus.
Ne pas empiler trop, mais votre question révèle une grave faille dans le système, qui est vous.
Vous êtes un seul point d'échec, et c'est assez loin des meilleures pratiques.
Selon les spécificités de ce contrat gouvernemental, avoir toutes les clés de chiffrement avec une seule personne peut être une violation disqualifiante, en plus d'être une mauvaise pratique. En plus de la question des "frappés par un bus", certaines réglementations gouvernementales exigent une mise en œuvre de la règle des deux hommes/principe des quatre yeux , souvent avec une barre d'accès minimale aux systèmes privilégiés surveillés ou audité par une personne autre que la personne accédant au système, ce qui n'est pas possible si vous êtes le seul à y avoir accès.
Aussi compréhensible que cela soit, vous êtes troublé en révélant des informations personnellement identifiables sur vous-même, ainsi que le fait que vous êtes probablement le meilleur point d'attaque contre ces systèmes, qui va dans les deux sens et devrait être troublant. L'approche appropriée n'est pas de masquer cette vulnérabilité, mais de la corriger. Si vous avez des systèmes et des processus sécurisés, ils sont sécurisés, que quelqu'un les connaisse ou non, et c'est sur cela que vous devriez vous concentrer. Il est tout à fait possible de placer vos serveurs dans un centre de données approprié et sécurisé, de mettre en place un contrôle/audit des accès et de vous éliminer en tant que point de défaillance unique, ce qui améliorerait la sécurité de vos systèmes et rendrait la réponse à ce questionnaire moins problématique . En tant que doublure argentée, c'est probablement une opportunité de revendre ce client particulier (et peut-être d'autres) sur ces améliorations de sécurité.
D'autres ont mentionné que vous êtes un point de défaillance unique dans les systèmes/processus de votre client, donc je ne répéterai pas tout cela.
Ce que je dirai, c'est que vous n'aurez peut-être pas à tout expliquer dans les moindres détails. Vous pourrez peut-être décrire vos systèmes comme vous l'avez fait dans la question. Tout cela dépend des questions qui vous ont été posées et de la juridiction légale par laquelle vous êtes régi.
Par exemple, vous n'aurez peut-être pas besoin de dire "Je conserve les clés et la configuration sur github", mais il se peut que vous ayez simplement besoin de dire "Je conserve les clés et la configuration dans un service de contrôle de version géré et privé tiers hébergé aux États-Unis. ". Ce dernier donne la juridiction légale des serveurs qui hébergent les données, mais ne donne pas nécessairement l'emplacement exact de celles-ci.
Une autre chose à noter est que si quelqu'un prend la bureaucratie très au sérieux, il est possible qu'il puisse, dirons-nous, avoir des complexes de supériorité non résolus. Autrement dit, ils peuvent poser des questions beaucoup trop détaillées ou précises, pour lesquelles il n'y a aucune justification dans la législation sur la protection des données. Ce n'est pas parce qu'ils ont demandé "Quelles mesures avez-vous prises pour sécuriser SSH? Veuillez détailler les autres ports utilisés, les séquences de détournement de port ou d'autres détails requis pour l'accès", cela ne signifie pas que vous devez réellement leur divulguer tout cela.
Cela dit, votre client direct a absolument le droit de demander ce genre de choses (parce que si vous êtes frappé par un bus, ce sont eux qui essaient de faire fonctionner les choses sans vous). Il n'y a (probablement) aucune loi régissant cela, à part "si vous ne le faites pas, ne vous attendez pas à être embauché". Il est peut-être temps de commencer à discuter avec eux d'une sorte de solution d'entiercement.