👋

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:

1. Support Risk Management
2. Enable Organizational Agility
3. Design Security to Balance Productivity with Protection
4. Control Third-Party Solutions
5. Utilize Secure by Design
6. Verify and Validate Security Design
7. Design for Compliance
8. Assume Compromise
9. Utilize Defense in Depth
10. Design Systems to Fail Securely
11. Support Security through Simplicity
12. Support Automation of Security Processes and Activities
13. Explicitly Verify Security Elements
14. Leverage Established Security Control Frameworks

PS. Masz pytania? Pisz śmiało po drugiej stronie to nie bot na bazie GPT czy Claude 😎