Zoals vermeld in de commentaren, ben ik het er ook mee eens dat 4 uur in een maand veel te laag is. Begrijp, en nog belangrijker, laat uw belanghebbenden begrijpen dat ze met 4 uur niet veel mogen verwachten. Aangezien ze je 4 uur hebben gegeven, lijkt het erop dat ze ook niet serieus zijn over het beveiligen van deze applicatie.

Op basis van de opmerkingen, antwoorden en mijn eigen gedachten zal ik proberen iets samen te stellen. Hier is hoe ik denk dat uw opties er in volgorde uit moeten zien.

1. Vraag om meer tijd. Laat ze begrijpen of ze een applicatie in slechts 4 uur willen beveiligen, het praktisch nutteloos is.
2. Huur een bureau in en besteed uw 4 uur aan het bepalen van hun reikwijdte, het prioriteren van hun acties en het bekijken van hun resultaten. (@Nelson)
3. Als je het bovenstaande niet kunt, raad ik aan om de laaghangende vruchten vast te zetten, zodat je in 4 uur meer grond bedekt. Dit is wat ik belangrijk vind
   • Stel uw externe services in om te updaten. (~ 1 uur om de belangrijke applicaties voor update te vinden en in te stellen). Sluit onnodige poorten / services die u niet nuttig vindt.
   • Stel MFA in (~ 10 minuten) - aangezien u niet veel tijd heeft, stelt u dingen in die snel zijn, beschermt u tegen veelvoorkomende aanvallen en waarschuw u.
   • Bekijk uw geheimen - Zorg ervoor dat ze veilig zijn opgeslagen, voer scanners uit op uw code om hardgecodeerde geheimen te vinden. (~ 1 uur)
   • Disaster Recovery - Ik zou aanraden om een ​​deel van je kostbare 4 uur te besteden aan het opzetten van bescherming voor als er iets misgaat, want dat zal gebeuren. Begin met het maken van back-ups (2 indien mogelijk) in verschillende zones. Ik neem aan dat het platform je hiermee zal helpen, maar het zal nog steeds tijd kosten. Gedurende deze tijd kunt u ook een globaal noodherstelplan opstellen. (~ 1.5h)
   • Eindelijk, met de weinige tijd die je nog hebt, documenteer. Documenteer wat je hebt gedaan, wat je niet hebt gedaan en wat de volgende stappen zouden moeten zijn voor de volgende keer dat iemand 4 uur krijgt om de applicatie verder te beveiligen. (~ overgebleven)

DoS-bescherming is goed en vereist, maar ik kon gewoon geen manier vinden om het in het bovenstaande plan te passen en ik kon er ook niets voor ruilen. Misschien moet dat in je volgende stappen worden gedocumenteerd.

Over het algemeen is het een vergezocht verzoek om iets binnen 4 uur te beveiligen. Maar als ik ermee zou worden belast, zou ik het doen met de bovenstaande stappen. Ik weet niet zeker of onderzoek of het systeem al is gehackt mogelijk is in die 4 uur. Wanneer u 4 uur de tijd krijgt om te beveiligen, kunt u ervoor kiezen om deze te besteden aan het beveiligen van de toepassing tegen mogelijke bedreigingen of om te onderzoeken op aanvallers in uw systeem (heeft een ander plan nodig). Die eerste keuze is aan jou.

Begin met de beste Azure-best practices voor beveiliging, zodat u de beveiliging van uw Azure-oplossing stap voor stap kunt onderhouden en verbeteren:

1. ga akkoord en upgrade uw Azure-abonnement naar Azure Security Center Standard. Dit zal u helpen beveiligingsproblemen op te sporen en op te lossen, toegangs- en applicatiecontroles toe te passen om kwaadwillende activiteiten te blokkeren, bedreigingen te detecteren met behulp van analyses en direct op aanvallen te reageren;
2. uw sleutels, databasereferenties, API-sleutels en certificaten op te slaan in Azure Key Vault. Zorg er bovendien voor dat sleutels en geheimen in de oplossing niet worden opgeslagen in de broncode van de applicatie;
3. installeer een webapplicatie-firewall (WAF) die een functie is van Application Gateway en die uw webapplicatie beschermt tegen veelvoorkomende exploits en kwetsbaarheden;
4. meervoudige verificatie afdwingen voor uw beheerdersaccounts;
5. uw virtuele harde-schijfbestanden coderen;
6. virtuele Azure-machines en -apparaten verbinden met andere apparaten door ze op virtuele Azure-netwerken te plaatsen;
7. mitigeren en beschermen tegen DDoS met DDoS Protection Standard die extra mitigatiemogelijkheden biedt;

Wanneer u klaar bent met de 1-7, focus dan op:

8. beheer van uw VM-updates aangezien Azure Windows-updates niet automatisch pusht
9. zorg ervoor dat u processen instelt voor belangrijke cloudbewerkingen zoals patchbeheer, back-up, incidentbeheer, wijzigingsbeheer, noodgebruikerstoegang, bevoorrechte toegang;
10. wachtwoordbeheer inschakelen en gepast beveiligingsbeleid gebruiken om misbruik te voorkomen;
11. uw Security Center-dashboard bekijken om een ​​overzicht te behouden van de beveiligingsstatus van al uw Azure-resources, zodat u indien nodig actie kunt ondernemen op basis van de aanbevelingen;

Lees de Microsoft-documentatie over de aanbevolen procedures voor Azure-beveiliging.

Documentatie:

Microsoft Azure Security Fundamentals

Microsoft Azure-beveiligingsdocumentatie

Dit is een zeer vreemd antwoord (oftewel het heeft weinig te maken met daadwerkelijke beveiliging), dus voel je vrij om mijn advies te negeren. Deze vraag zelf is redelijk gebaseerd op meningen, dus ik dacht dat ik een heel ander "soort" antwoord zou proberen.

U bent belast met de beveiliging van applicaties. Dit is een goede zaak!

Helaas heeft uw werkgever een zeer onrealistische verwachting van wat er nodig is om een ​​sollicitatie veilig te stellen. 4 uur is lang niet genoeg tijd om dit werk goed te doen. Voor de duidelijkheid: dit is nog steeds beter dan de meeste bedrijven (die exact 0 uur per maand toegewijde beveiligingstijd toewijzen). De realiteit is echter dat 4 uur een schijntje is. Dus dit is wat je doet:

1. Ren met alle suggesties die mensen hier geven
2. Besteed veel meer dan 4 uur per maand
3. Om te vermijden uw werkgever ongelukkig maken of orders direct niet gehoorzamen, doe het extra werk in uw eigen tijd. Plan om de komende maanden regelmatig een flink stuk extra uren te besteden.
4. In deze tijd leert u zaken als het beoordelen van code op zwakke punten in de beveiliging, het installeren en gebruiken van SEIM-systemen, het installeren en gebruiken van logsystemen (ELK-stack wordt vaak gebruikt), inbraakdetectiesystemen, automatisch scannen van applicaties en meer! (de volledige lijst is waarschijnlijk te lang, leer het allemaal in een paar maanden werken in je vrije tijd, maar doe je best!)
5. Je bedrijf krijgt uiteindelijk de voordelen van je gratis arbeid, wat een beetje triest is, maar ...
6. Je bent goed op weg om jezelf op te leiden tot beveiligingsprofessional (als je een functie wilde, ben je op weg om een ​​sollicitatie Security Engineer) als onderdeel van uw officiële taken, het beveiligen van een daadwerkelijke webapplicatie in productiegebruik!
7. Begin met solliciteren voor uw volgende baan als Application Security Engineer. U zult waarschijnlijk een betere baan vinden door werk te doen dat leuker is, en u zult waarschijnlijk ook beter betaald worden!

Uiteraard kan ik geen garanties geven over hoe het zou aflopen, maar wat je in feite hebt gekregen, is toestemming om jezelf te trainen voor een carrièreverandering. Een kans om in uw toekomst te investeren! Er is zelfs meer vraag naar beveiligingsprofessionals dan naar ingenieurs, dus persoonlijk zou ik dit nemen en ermee aan de slag gaan. Vooral als het in mijn voordeel zou werken, zou ik mijn huidige werkgever niet eens misgunnen voor het gratis werk dat ik ze zou geven vanwege hun kortzichtigheid.

Ik raad aan om

1. te beginnen met een risicobeoordeling
2. compileer de hier gegeven lijsten (zowel door uzelf als in de antwoorden ) in bruikbare items
3. Ga terug naar uw superieuren met het resultaat en vraag om meer tijd of een prioriteitstelling door hen.

Zoals anderen al hebben gezegd, is 4 uur veel te weinig moeite, maar ik zal enkele aanbevelingen doen voor het geval je ze nuttig vindt.

• Voer een kwetsbaarheidsscanner uit, zoals Qualys of iets dergelijks. Dit zal een aantal nuttige app-kwetsbaarheden oppikken, zoals XSS, SQL-injectie, CSRF en dergelijke.
• Voer een tool voor codebeoordeling uit om voor de hand liggende slechte praktijken te identificeren (dwz gebruikersinvoer niet correct te ontlopen voordat deze naar de database wordt verzonden)
• Installeer een goede interne (hostgebaseerde) en externe ( edge- of cloudgebaseerd) WAF die beschermt tegen OWASP-bedreigingen en meer. Verschillende cloudgebaseerde WAF's bieden bescherming tegen DDoS en sommige brute force-aanvallen.
• Isoleer uw infrastructuur in vlan-zones door vertrouwen en zorg voor minimale gegevensstromen tussen hen (bijv. Edge, presentatie, bedrijfslogica, gegevens)
• Iemand anders heeft het eerder genoemd, maar erg belangrijk: zorg ervoor dat u slaan geprivilegieerde inloggegevens (API-sleutels, db-creds enz.) apart van de broncode op.
• Versterk alle infrastructuur.
• Het kan even duren, maar ik raad u aan een heatmap of een gebalanceerde scorekaart van beveiligingsrisico's te maken en ervoor te zorgen dat deze zichtbaar is voor uw senior stakeholders. Goede beveiligingspraktijken kunnen risico's verminderen, maar geen enkele is op zichzelf een wondermiddel.

Ik ga ervan uit dat de applicatie extreem klein is, je schrijft scripts voor de logboeken om te zoeken naar dingen die niet op hun plaats zijn (idealiter gebeurt dit niet tijdens de 4 uur werkperiode), noodherstel zou al aanwezig moeten zijn voor een grote applicatie (controleer of de applicatie een dergelijke inspanning vereist.).

1. Documentatie is van vitaal belang omdat het u zou moeten laten weten wat er wordt gebruikt en wie het ook gebruikt, hoe vaak het wordt gebruikt. Dit zal helpen bij het ontwikkelen van het script.

2. Scripts zijn nodig om de logboeken van een maand te verdichten, dus kies zorgvuldig.

3. Controleer back-ups.

4. Controleer altijd de gebruikte technologieën en of er sprake is van POC of exploits. Spring er niet in en begin zelf een exploit te proberen, je hebt maar 4 uur.

5. Verzoek om aanvullende ondersteuning als de toepassing van vitaal belang is.

Idealiter zouden alleen de documentatie en scripting tijd moeten kosten, rust zou redelijk eenvoudig moeten zijn. Dit is niet het beste wat je nodig hebt om de waarde van het project te bepalen en te kiezen of 4 uur voldoende is.

Als je je doelwit begrijpt, kun je het beter beschermen.

Ik weet zeker dat er een beter antwoord is, hopelijk zullen ze het geven.

OP, het lijkt erop dat je voornamelijk een ontwikkelaar bent, kijkend naar je bijdragen. Dus wat kan een ontwikkelaar doen om de beveiliging te verhogen?

In de eerste maand:

• 2 uur: probeer een versie een aantal externe afhankelijkheden / componenten / bibliotheken tegen te houden en probeer om de app opnieuw te bouwen. Documenteer de onverenigbaarheden als je faalt.
• 2 uur: doe wat nodig is om je eigen wijzigingen door CI / CD te pushen, door te testen, door de master branch en naar productie. Probeer andere ontwikkelingen te meeliften als die er zijn, maar let in dit geval vooral op het achterlaten van sporen die u daadwerkelijk iets nuttigs hebt gedaan (bv. Enkele PR's schrijven).

Herhaal elke maand, maar pas de scheidingslijn tussen de twee gaandeweg aan. (De kans is groot dat de laatste splitsing meer zal zijn als 10 minuten versus 3 uur en 50 minuten.)

Op deze manier repareer je de ergste vector - dat een van de populaire componenten / bibliotheken een maanden oude gepubliceerde kwetsbaarheid heeft ( CVE). Zwermen bots beginnen de hele internetpwning elke kwetsbare implementatie te scannen. Als je alleen de componenten van derden upgradet, zelfs alleen door (geïnformeerde?) Gissingen te doen, is er een behoorlijke kans dat je nooit het slachtoffer wordt en nooit nodig zult hebben om de echt onaangename situaties aan te pakken.

Dat is nogal triviaal voor ontwikkelaars, maar in de meeste bedrijven vermijden ontwikkelaars dergelijk oninteressant onderhoud. Het wordt een groot probleem voor de typische beveiligingsafdelingen (omdat ze applicaties niet opnieuw compileren). De grote inspanningen om "logboeken te analyseren" of "WAF's te implementeren" of "kwetsbaarheidsscans uit te voeren" zijn er voornamelijk om die kloof vanuit alle resterende mogelijke hoeken te dichten.

Op basis van je vraag lijkt het erop dat je vraagt ​​hoe je je leren kunt focussen. Ik zou die veronderstelling hier en nu willen uitdagen. Degene die u 4 uur per maand heeft toegewezen, heeft al zijn eigen aanvraag afgebroken om te profiteren van uw zelfstudie. Onverantwoordelijk van hen! Om iets te leren dat aan dit project is gewijd, implementeer het dan, leer dan over uw fouten en herhaal ... Dat kan niet elke maand in stukken van 4 uur worden gedaan. "Repareer" dit niet, want het was niet jouw beslissing! Doe in de tijd van dit project dingen die je al goed weet.

Dat is een starter. Wat u in uw eigen vrije tijd probeert te leren en te implementeren, is uw voorkeur en uw eigen zaken. Ik denk dat het te breed is voor deze site (omdat je misschien besluit dat je niet geïnteresseerd bent in beveiliging, wat helemaal goed is), maar anderen gaven je sowieso heel veel leads. Zoek ook naar nuttige dingen tijdens je andere projecten. Sommige van de eerste of de laatste passen in deze 4 uur en helpen de staat van het project te verbeteren.

Van een systeembeheerder die zulke dingen heeft moeten doen, zou ik aanraden om gewoon een dev-VM te maken die je kunt vervangen door prod.

1. Maak een back-up van je server.
2. Scheid uw databases op hun eigen servers. Zorg ervoor dat ze alleen kunnen communiceren met ÉÉN IP-adres, de productieserver / -service die het nodig heeft. (Eenmalige wijziging, erg belangrijk.)
3. Kloon de hoofdserver en geef de nieuwe een ander IP-adres.
4. Breng alle noodzakelijke wijzigingen, updates, beoordelingen en controles aan.
5. Wanneer het venster van 4 uur beschikbaar is, brengt u de services op de hoofdpagina naar beneden.
6. Back-updatabases. KRITISCHE STAP.
7. Push alle lokale wijzigingen van main naar cloned.
8. Zorg ervoor dat alles er goed uitziet en naar behoren werkt.
9. Verwissel de IP-adressen voor main en cloned .
10. Gekloond is nu het hoofdbestand.
11. Maak nog een back-up van alles. (Ja, doe er nog een.)
12. Roep de services op main.
13. Laat het andere systeem met rust als back-up voor het geval er iets gebeurt.

Je noemt de risico's niet: slaat het persoonlijke gegevens op, enz. Maar als het een complexe applicatie is, dan is een aanpak die behoorlijk tijdbesparend is, fuzz-testen: haal enkele geldige verzoeken uit de logboeken, muteer ze met het soort metatekens dat in een injectie-aanval zou kunnen zitten, en die een kwetsbaarheid rapporteren elke keer dat je een 500-fout krijgt.

Helaas is de gebruikelijke reactie "dat kan niet worden misbruikt", vooral in een beveiligingsnaïeve omgeving zoals je lijkt te zijn. En het omzetten van een kwetsbaarheid in een exploit kost meer dan uw gebudgetteerde vier uur.

Alternatief antwoord: besteed de tijd aan het poetsen van je cv, want deze werkgever kan op elk moment failliet gaan.