Esta é a terceira de nossa série de várias partes sobre a aplicação de abordagens de segurança da informação à modelagem de dados. A série usa um modelo de dados simples, algo para gerenciar clubes sociais e grupos de interesse, para fornecer o conteúdo que procuramos proteger. Posteriormente abordaremos a modelagem para autorização e gerenciamento de usuários, bem como outras partes de uma implementação segura de banco de dados.
Em situações sociais, é comum “ler nas entrelinhas” – deduzindo as suposições e afirmações não ditas em uma conversa. O mesmo ocorre na criação de software e armazenamento de dados em um banco de dados. As faturas são enumeradas com o ID do cliente incorporado e quantas entidades de dados usam uma data e hora como parte da chave? É difícil imaginar documentar ou estruturar tudo completamente sem algum tipo de omissão. Mas em nossa última parte, passamos exatamente por esse exercício. Conseguimos atribuir sensibilidade a várias partes do banco de dados do nosso clube social. Mas para quantificar e gerenciar essa sensibilidade, devemos aumentar a estrutura do nosso modelo de dados para tornar os dados confidenciais e seus relacionamentos claros.
Fechando as lacunas do modelo de dados
A modelagem de dados para segurança requer várias variedades distintas de mudanças de estrutura. Estamos explorando estes, por sua vez, usando um modelo de dados de clube social (muito!) simples como nossa base para esta série. À medida que avançamos, aprimoramos o modelo com mais dados. Na última parte, analisamos o modelo para atribuir a sensibilidade dos dados onde o encontramos. Esta análise também revelou que havia lugares onde o modelo de dados indicava links que não eram realmente capturados explicitamente em colunas e relacionamentos de chave. O modelador deve esperar isso em uma análise de segurança. Avançando a partir dessas descobertas, tornaremos essas relações o mais concretas e claras possível construindo as tabelas e as conexões entre elas. Isso nos permitirá anexar atributos de segurança mais adiante.
Construindo os relacionamentos de dados no clube
Todos os relacionamentos nos dados, bem como as próprias entidades de dados, devem ter alguma representação para atribuir valor ou sensibilidade a eles. Novas colunas, novas chaves, novas referências e até novas tabelas podem ser necessárias para fazer isso. Quando analisamos as tabelas e seus relacionamentos em nosso último post, isolamos duas tabelas principais com dados de alta sensibilidade:
PersonPhoto
Além disso, tínhamos quatro contendo dados moderadamente sensíveis:
MemberClubOfficeClub_Office
Esses aspectos de sensibilidade são parcialmente intrínsecos a cada tabela, mas relacionamentos não explícitos carregam muito da sensibilidade. Para anexá-lo, começamos a registrar as relações e damos a elas uma estrutura para conter a sensibilidade.
Relacionamentos incorporados em fotos
Photo contém muitos relacionamentos incorporados que precisamos capturar. Principalmente, estamos interessados no relacionamento com Person . Para capturar a relação Pessoa-Foto, estou adicionando o Photo_Content tabela:Há muitos aspectos diferentes pelos quais uma
Person pode estar relacionado a uma Photo . Decidi adicionar uma nova tabela, Photo_Content_Role , para caracterizar a relação de uma Foto com uma Pessoa. Em vez de ter tabelas separadas para cada tipo de relacionamento, usamos uma única tabela de conexão e a tabela Photo_Content_Role. Esta tabela é uma lista de referência com relacionamentos padrão como o que já observamos. Aqui está nosso conjunto inicial de dados para Photo_Content_Role :| Etiqueta | Máx. por pessoa | Descrição |
|---|---|---|
| Fotógrafo | 1 | A pessoa que realmente tirou a foto |
| Pessoa Representada | 1 | Uma pessoa reconhecível na foto |
| Proprietário dos direitos autorais | 1 | Uma pessoa que detém os direitos autorais da foto |
| Licenciador | 1 | Uma parte que licenciou o uso desta foto pelo clube |
| Corretor de direitos autorais | 1 | Uma parte que resolveu problemas de direitos autorais para esta foto |
| Objeto representado | ilimitado | content_headline identifica o objeto, content_detailed elabora |
| Comentário | ilimitado |
OK, então isso é uma isca e troca. Eu disse
Photo_Content relacionaria pessoas para fotos, então por que há algo sobre “objeto retratado”? Logicamente, haverá fotos em que descreveríamos o conteúdo sem identificar uma Pessoa . Devo adicionar outra tabela para isso, com um conjunto separado de funções de conteúdo? Eu decidi que não. Em vez disso, adicionarei uma linha de pessoa nula à Person tabela como dados de semente e ter conteúdo não-pessoal referindo-se a essa pessoa. (Sim, programadores, é um pouco mais de trabalho. De nada.) A 'null Person' terá id zero (0). Aprendizado-chave nº 1:
Minimize tabelas com dados confidenciais sobrepondo estruturas de relacionamento semelhantes em uma única tabela.
Prevejo que pode haver relacionamentos adicionais que serão descobertos a jusante. E também é possível que um clube social tenha suas próprias funções para atribuir a uma Pessoa em uma foto . Por esse motivo, usei uma chave primária substituta "pura" para Photo_Content_Role , e também adicionou uma chave estrangeira opcional ao Club . Isso nos permitirá apoiar usos especiais de clubes individuais. Chamo o campo de 'exclusivo' para indicar que não deve estar disponível para outros clubes.
Aprendizado-chave nº 2:
Quando os usuários finais puderem estender uma lista integrada, dê à tabela uma chave substituta pura para evitar colisões de dados.
Photo_Content_Role.max_per_person também pode ser misterioso. Você não pode vê-lo no diagrama, mas Photo_Content_Role.id carrega sua própria restrição exclusiva sem max_per_person . Em essência, a chave primária real é apenas id . Adicionando max_per_person para id na chave primária, forço cada tabela de referência a receber informações pelas quais ela pode (deve!) impor uma restrição de verificação de cardinalidade. Aqui está a restrição de verificação em Photo_Content .
Aprendizagem chave nº 3:
Quando cada linha de uma tabela tem restrições individuais, as tabelas de referência devem adicionar uma nova restrição exclusiva, estendendo uma chave natural com os campos de restrição. Faça com que a tabela filha se refira a essa chave.
Vamos dar uma olhada em Photo_Content . Esta é principalmente uma relação entre Photo e Person , com o relacionamento especificado pela função de conteúdo anexada. No entanto, como observei anteriormente, é aqui que armazenamos todos informações descritivas sobre a foto. Para acomodar esse tipo de abertura, temos o opcional content_headline e content_detailed colunas. Eles raramente serão necessários para uma associação comum entre uma Pessoa e uma Foto. Mas uma manchete como “Bob Januskis Recebe o Prêmio Anual de Realização” é fácil de prever. Além disso, se não houver Pessoa — 'Objeto representado', Pessoa 0 — devemos exigir algo no content_headline , como 'Declive Noroeste do Monte Ararat.'
A última relação de fotos perdidas:álbuns
Até agora, não adicionamos nada relacionado a
Photo s para Photo s. É uma grande coisa para redes sociais e serviços de fotos:Album s. E você não os quer na caixa de sapatos proverbial, não é? Então, vamos preencher essa lacuna gritante – mas vamos pensar sobre isso também. Album anexa Photo s de uma maneira diferente dos outros relacionamentos que abordamos. Photo s podem ser associados pelo mesmo clube, uma data semelhante, coordenadas GPS próximas, o mesmo fotógrafo e assim por diante. No entanto, Album indica claramente que a Photo s fazem parte de um único tópico ou história. Assim, os aspectos relevantes de segurança de uma Photo pode ser inferido de outro no Album . Além disso, a ordenação pode amplificar ou diminuir essas inferências. Portanto, não pense apenas em Album como uma coleção inócua. Relacionando Photo s é tudo menos isso. Embora não seja inócuo do ponto de vista da segurança,
Album é uma entidade direta com um Id puro chave substituta de propriedade de um Club (não uma Person ). Album_Photo nos fornece um conjunto de Photo s sequenciados por Photo_Order . Você notará que fiz o Album id e order a chave primária. A relação é realmente entre a Photo e o Album , então por que não torná-los a chave primária? Porque casos estranhos que exigem uma Photo para repetir em um Album certamente são possíveis. Então eu coloquei Photo_Order na chave primária e, depois de pensar um pouco, decidiu adicionar uma chave única alternativa com álbum e foto para evitar uma Photo de repetir em um Album . Se o suficiente chorar por repetir uma Photo em um Album surgir, uma chave única é mais fácil de remover do que uma chave primária. Aprendizado Chave Nº 4:
Para a chave primária, selecione uma chave candidata com o menor risco de ser descartada posteriormente.
Metadados de fotos
A última informação potencialmente sensível a ser adicionada são os metadados (geralmente criados por qualquer dispositivo que tenha tirado as fotos). Esses dados não parte de um relacionamento, mas é intrínseco à foto. A principal definição de informação que uma câmera armazena com uma foto é EXIF, um padrão da indústria do Japão (JEITA). EXIF é extensível e pode suportar dezenas ou centenas de campos, nenhum dos quais pode ser exigido de nossas imagens enviadas. Esse status não obrigatório ocorre porque esses campos não são comuns a todos os formatos de foto e podem ser apagados antes do upload. Eu criei
Photo com muitos campos comumente usados, incluindo:- camera_mfr
- modelo da câmera
- camera_software_version
- imagem_x_resolução
- imagem_y_resolução
- image_resolution_unit
- image_exosure_time
- camera_aperture_f
- GPSLatitude
- GPSLongitude
- GPSA Altitude
Os campos GPS são, naturalmente, os que adicionam a maior sensibilidade a uma Photo .
Nosso modelo, com todos os dados confidenciais e valiosos definidos
Concluímos esta fase de proteção do banco de dados do clube com essas alterações. Todas as conexões e os dados adicionais necessários estão presentes, conforme ilustrado abaixo. Eu fiz
Photo informações em vermelho e Album turquesa claro para transmitir minha ideia de agrupamentos lógicos. O aumento de elementos de dados é real, mas muito minimizado. Conclusão
Colocar qualquer modelo de dados em uma boa base de segurança requer uma aplicação ordenada e sistemática de princípios de segurança, bem como uma prática de banco de dados relacional. Nesta parte, revisamos o modelo de dados e preenchemos cuidadosamente a estrutura ausente que estava implícita, mas não expressa no esquema. Não poderíamos atribuir valor ou fornecer proteção aos dados existentes sem adicionar os dados que os preenchem e os vinculam corretamente. Com isso em vigor, continuaremos a anexar os elementos de avaliação de dados e sensibilidade de dados que nos permitirão ver claramente todos os dados de uma perspectiva de segurança completa. Mas isso fica no nosso próximo artigo.
