Security Think Tank: Kısa bir (güvenli) kodlama tarihi


Sürekli artan bir hızla ilerleyen teknoloji ile geliştiriciler, kodu güvende tutma ve sürekli artan siber güvenlik tehditlerine karşı önlem alma konusunda her zamankinden daha fazla zorlanıyor. Ancak, sahada 20 yılı aşkın bir süredir çalışarak elde edilen örneklerin kullanılması, her zaman aşılması gereken engellerin olduğunu göstermektedir.

IBM ana bilgisayarı

IBM anabilgisayar kodlaması, büyük karmaşık hiyerarşik veritabanlarını okumak/güncellemek için gecelik toplu işlemler olarak çalışacak şekilde programlanmış COBOL/PLI programları yazmakla ilgiliydi. Kaynak Erişim Kontrol Tesisi (RACF), en az ayrıcalık ilkesine dayanan bir güvenlik modeliyle kritik kaynaklara kullanıcı erişimini yönetti. Doğru erişim düzeyine sahip bir hesabın kullanılması, kullanıcı hesabının veritabanının bir şubesine okuma veya yazma için uygun erişimi olmadığından iş çalıştırmalarının durmasını veya başarısız olmasını önlemek için çok önemliydi.

Müşteri sunucusu

Sırada, bir IBM DB2 veritabanında depolanan satın alma siparişlerini artırmak için Nesne Yönelimli Smalltalk-80 dili kullanılarak ön uç geliştirme vardı. Smalltalk, yerleşik güvenliği olmadan kapsüllemeyi destekledi – nesneler dahili durumu kapsülledi ve veri güvenliği, nesneler arasındaki veri akışını kontrol ederek korundu. Bilgi akışı, nesnelerin bulunduğu güvenlik düzeylerini geliştirmek için bir protokol kullandı; bilgi daha güvenli bir seviyedeki bir nesneye iletilebilir, ancak daha az güvenli bir seviyedeki bir nesneye aktarılamaz.

SAP Dynpro

Bunu, ABAP kullanılarak SAP Dynpro geliştirme izledi. İşlem kodları ve yetkilendirme profilleri günün sırasıydı ve geliştiricilerin, bir kullanıcı hesabının uygulamaya erişmek, veritabanını okumak/yazmak vb. için doğru yetkilendirme profiline sahip olup olmadığını test etmek için koda uygun kontrolleri eklemesi bekleniyordu. yanlış, son kullanıcının ‘Yetkisiz’ uyarılarıyla karşı karşıya kaldığını gördü – veya etkinliklerine asla itiraz edilmemesi için çok fazla erişim verildi.

2017, SAP sistemlerine dolaylı erişim kavramını gündeme getiren yüksek profilli bir davanın ardından SAP kullanan şirketler için bir dönüm noktası oldu. Tüm uzaktan erişim/uzaktan işlev çağrıları (RFC) için sıklıkla tek bir hizmet hesabı (genellikle SAP_ALL erişimi olan) kullanıldı ve geliştiriciler bu hesapların parolalarını biliyordu. Kuruluşlar, her uygulama için hızlı bir şekilde bireysel hesaplara geri döndü.

web Geliştirme

SAP Enterprise Portal (WebDynpro Java/Java Sunucu Sayfaları) ve SAP Web Uygulama Sunucusu (WebDynpro ABAP), SAP ortamında tarayıcı tabanlı geliştirme için kapıları açtı. Java kodunu geliştirmek ve dağıtmak, yerel olarak kurulmuş bir geliştirme platformu (Eclipse) gerektiriyordu ve geliştiricilerin, kısıtlı erişime sahip güvenli ağ sürücülerinde depolanan kod havuzlarıyla kod tabanının güvenli olduğundan emin olmaları gerekiyordu.

Bir web uygulamasının perde arkası karmaşıktır ve birçok kullanıcı HTTP hata mesajlarıyla karşılaşmıştır. Etkili sorun giderme, mimari ve ağ düzeyinde farkındalık gerektiriyordu – Yük Dengeleyiciler, DNS, bağlantı noktası eşleme, ters proxy sunucuları, etki alanı gezintisi, sertifikalar vb. sınırlı.

Geliştiricinin en iyi uygulaması, harici olarak imzalanmış sertifikalar ve endüstri standardı bir şifreleme düzeyi ile web geliştirme için her zaman bir HTTPS bağlantı noktasının kullanılmasını sağlamalıdır.

Tek Oturum Açma (SSO) ve Çok Faktörlü Kimlik Doğrulama (MFA)

Temel kimlik doğrulama (kullanıcı kimliği ve parola), SSO’yu simüle etmek için hesap ve parola ayrıntılarını URL’lerde görünür parametreler olarak geçirerek istismara karşı savunmasız hale getirdi; Bu nedenle, uygulamalara SSO’yu etkinleştirmek için oturum açma belirteçlerinin ve sertifikalarının benimsenmesi oyunun kurallarını değiştirdi.

Bir kullanıcının kimliğini içeren Kerberos belirteçleri, diğer birçok SAP sisteminde oturum açmak için bir SAP Oturum Açma Bileti oluşturmak üzere kullanıcı kimlik bilgilerini tanımlama bilgisi olarak ileten şirket içi bir SAP sistemine SSO için kullanılabilir. Ancak tanımlama bilgileri kötüye kullanıma açık olduğundan, yalnızca hedef sistemle sınırlı olduklarından ve bir tanımlama bilgisi yerine bir HTTP başlığı olarak iletildiklerinden SAP Onaylama Biletleri tercih edilir.

SAML 2.0, web tabanlı kimlik doğrulama ve yetkilendirme için açık standart olarak ortaya çıkmıştır. Kimlik sağlayıcı, yalnızca kullanıcının kimliği onaylandıktan sonra bir oturum açma belirteci verir ve bu SAML 2.0 belirteci, hizmet sağlayıcı barındırma uygulamasına iletilir. SSL, şifreleme, sınırlı belirteç geçerliliği vb. kullanımı, kötüye kullanımı azaltır.

Mobil ve API geliştirme

API geliştirme, sistemden sisteme RFC veya web hizmetleri yoluyla ve genellikle ek ara katman yazılımı veya hizmet arabuluculuk katmanları aracılığıyla veri paketlerinin sistemler arasında güvenli bir şekilde aktarılması anlamına gelir.

Genellikle kaynak sistemden hedef tarafından alınabilecek farklı bir biçime dönüştürülen veri paketlerinin yanı sıra SAML 2.0 – OAuth 2.0 gibi kimlik belirteçleri alışverişi ile API’nin tüm yolculuğunun anlaşılmasını gerektirir.

REST (en yaygın web hizmetlerinden biri) geliştirmesi için OAuth 2.0, bir uygulamanın web API aracılığıyla diğer sistemlerdeki kaynağa erişmesine izin vermek için kapsamları kullanır. Kapsam, kullanıcıların uygulamalara erişimini sınırlar; bu nedenle, yetkilendirme modelinin bir parçası olarak kapsamların iyi tasarımı, doğru erişim düzeyini sağlamak için çok önemlidir.

Tarayıcı uyumluluğu ve cihazlar arası

En yeni tarayıcılar, siber güvenlik tehditlerini azaltmak için sürekli artan güvenlik önlemlerine sahiptir. Tarayıcı öykünme moduna (yani, IE 5 gibi eski sürümlere öykünmeye) güvenen şirketler, kodun güvenliğini sağlamak için planlanmamış geliştirme çalışması gerektiğinden, yıllarca çalışan web uygulamalarının Chromium veya Edge Chromium gibi modern tarayıcılarda çalışmayı bıraktığını fark eder.

Mobil geliştirme, bir ağ bağlantısının kesilmesi durumunda uygulamanın kaldığı yerden devam etmesini sağlayan, cihazda depolanan çevrimdışı verilerle başka bir öğe ekler. Bunu başarmak için ‘Çevrimdışı OData’ ve benzer teknikler, geliştiricilerin cihazda yalnızca minimum miktarda verinin depolanmasını (işlemi mümkün olduğu kadar güvenli tutmak için) ve bir kez bağlantı kurulacak şekilde ‘senkronizasyon noktasını’ yönetmesini gerektirir. geri yüklenen veriler kaynağına güvenli bir şekilde yüklenebilir / senkronize edilebilir.

Sürekli entegrasyon/teslim/dağıtım

Kuruluşlar, kalite veya güvenlikten ödün vermeden daha hızlı geliştirme yaşam döngüsü süreleri sağlayan “çevik proje” teslimi için çabalar. DevOps yaşam döngüsünün otomasyonu (kod emsal incelemeleri, derlemeler, devreye alma, test etme, onaylar, geliştirmeden üretime geçiş yaşam döngüleri için sürekli entegrasyon, teslim ve dağıtım boru hatları yoluyla), geliştiricinin kodu bir kod havuzuna kontrol ettiği anı tetikler.

Onapsis ve SonarQube gibi kod tarama araçları, ABAP’tan XML’e kadar çeşitli kod tabanlarında güvenlik açıklarını işaretleyerek en iyi güvenli kodlama uygulamaları için kodu taramak üzere DevSecOps ardışık düzeninin bir parçası olarak entegre edilebilir.

Ancak, tuzaklar var. Genellikle kod taramaları en son kod sürümüne göre optimize edilir ve eski bir kod satırı risk olarak işaretlenebilir. Çok sayıda yanlış pozitiften kaçınmak için eşiklerin, güvenli olan ancak eski bir teknik kullanılarak yazılmış kod için bir uyarıyı yok sayacak veya ayarlayacak şekilde yapılandırılması gerekir. Uyarılar, DevSecOps ihlallerini en aza indirmek için geliştirme ekipleri arasında daha iyi kodlama standartlarının geliştirilmesine yardımcı olacaktır.

Aynısından daha fazlası

Kodlamayı güvenli tutmak her zaman zorluklar sunmuştur. Bunların çoğu, teknoloji ve insan uzmanlığının bir araya gelmesiyle aşıldı – devam ettirilmesi gereken bir model.



Source link