👋
Dziś Szymon poleca artykuł o wyzwaniach w budowaniu zespołów na przykładzie modelu Spotify, a Łukasz komentuje najnowsze zasady bezpieczeństwa architektonicznego od The Open Group.
Sprawdź szkolenie z Łukaszem dla community Order of Devs - [28.08.2024] Szkolenie RKE2 i Rancher - uwaga, ze względu na pierwszą edycję cena jest mega promocyjna. Zaraz kończą się miejsca!
BTW, sprawdź też jesienne Patoszkolenia!
Szymon: "Trudniejsze" decyzje w budowaniu zespołów
Był taki moment, że każda organizacja chciała mieć, albo "miała" model zespołów ze Spotify. Wraz z czasem model ten obrósł w mity i legendy, a każdy rozumiał to co usłyszał inaczej. Kolejne artykuły i prelekcje z trzeciej ręki nie pomagały. Jednak czasem trafia się na analizy naukowe które pracowały z faktycznymi zespołami i przeanalizowali w jaki sposób realizowane są te niby oczywiste, ale w praktyce nie tak bardzo proste obszary Artykuł warty do przeczytania dla każdego kto myśli jak ułożyć zespoły. Nie tylko developerskie.
Łukasz: The Open Group Standard - Security Principles for Architecture
"Boomerzy" z The Open Group (ci od nudnego TOGAF-a) wydali "Security Principles for Architecture". Zasady bezpieczeństwa (wysokopoziomowe), które można stosować w ramach architektur korporacyjnych, architektur technologicznych, architektur rozwiązań i innych, jak to opisują.
Ciekawe, że dokument kładzie nacisk na automatyzację i "secure by design", co pokazuje ewolucję myślenia. Widać, że The Open Group dostrzega rosnące znaczenie tych aspektów w nowoczesnych architekturach (nigdy nie jest za późno 😅). W całości brakuje mi trochę krytycznego spojrzenia na potencjalne konflikty między zasadami, bo czasem trudno je wszystkie pogodzić w realnym środowisku.
Szybkie TL;DR:
- Dokument definiuje 14 kluczowych zasad bezpieczeństwa dla różnych typów architektur.
- Porównywanie bezpieczeństwa organizacji na podstawie tych zasad może być szkodliwe - każda ma swoje unikalne wymagania i kontekst.
- Śledzenie i porównywanie zgodności z zasadami może odwracać uwagę od rzeczywistego zwiększania bezpieczeństwa. ALE! Nie porzucajmy tego w 100%, tylko okresowo analizujmy, jak te zasady wpływają na nasze bezpieczeństwo.
- Zamiast walczyć o perfekcyjne wdrożenie wszystkich zasad, lepiej skupić się na ciągłym doskonaleniu i dostosowywaniu ich do konkretnych potrzeb organizacji.
Same zasady:
- Support Risk Management
- Enable Organizational Agility
- Design Security to Balance Productivity with Protection
- Control Third-Party Solutions
- Utilize Secure by Design
- Verify and Validate Security Design
- Design for Compliance
- Assume Compromise
- Utilize Defense in Depth
- Design Systems to Fail Securely
- Support Security through Simplicity
- Support Automation of Security Processes and Activities
- Explicitly Verify Security Elements
- Leverage Established Security Control Frameworks
PS. Masz pytania? Pisz śmiało po drugiej stronie to nie bot na bazie GPT czy Claude 😎
0 comments