સેવા
એપ્લિકેશન સુરક્ષા એન્જિનિયરિંગ
આ નિર્માણનો નિર્ણય છે, લોન્ચ પહેલાંનો તબક્કો નહીં.
એ ટીમો માટે જેમને સુરક્ષા સોફ્ટવેર વિશે લખાયેલો રિપોર્ટ નહીં, પણ સોફ્ટવેરનો ગુણ જોઈએ. અમે એ ભાગો પર કામ કરીએ છીએ જેમને પછીથી ઉમેરવા મોંઘા પડે છે — ઓથોરાઇઝેશન, સેશન સંચાલન, સિક્રેટ સંચાલન, નિર્ભરતા જોખમ — અને તેમને એવા ટેસ્ટથી સાબિત કરીએ છીએ જે સિસ્ટમ તોડવાનો પ્રયાસ કરે છે.
નિર્ણય
આ ક્યારે સાચો નિર્ણય છે.
જે સુરક્ષા લોન્ચના બે અઠવાડિયાં પહેલાં એક સ્કેન તરીકે આવે છે, તે સસ્તી વસ્તુઓ પકડે છે અને મોંઘી છોડી દે છે. ગુમ હેડર અને જૂની લાઇબ્રેરી ખરી છે, પણ ઉપરછલ્લી છે. તૂટેલું એક્સેસ કંટ્રોલ — જ્યાં કોઈ વપરાશકર્તા ઓળખક્રમાંક બદલીને બીજા ટેનન્ટના રેકોર્ડ સુધી પહોંચી જાય — બિઝનેસ સોફ્ટવેરની સૌથી સામાન્ય ગંભીર ખામી છે, અને કોઈ સ્કેનર તેને ભરોસાપૂર્વક પકડતું નથી, કારણ કે તે તદ્દન એક વાજબી વિનંતી જેવું દેખાય છે.
એ પ્રકારની ખામી આર્કિટેક્ચરની સમસ્યા છે. જો ઓથોરાઇઝેશન મેનુ આઇટમ છુપાવીને લાગુ થતું હોય, કે એવી ચકાસણીથી જેને કેટલાક રૂટ યાદ રાખે અને કેટલાક નહીં, તો પ્રશ્ન એ નથી કે છિદ્ર છે કે નહીં, પણ એ કે ક્યાં છે. બનેલી એપ્લિકેશનમાં એક સુસંગત મોડલ પછીથી નાખવું સૌથી મોંઘા ફેરફારોમાંનો એક છે.
તેથી અમે તેને નિર્માણનો નિર્ણય બનાવીએ છીએ: દરેક વિનંતી પર સર્વર તરફથી એ વપરાશકર્તા સામે ઓથોરાઇઝેશન જે કામ કરી રહ્યો છે, એવા ટેસ્ટ જે જાણી જોઈને બીજા ટેનન્ટનો ડેટા માગે છે અને ઇનકારની ખાતરી કરે છે, અને એવા સિક્રેટ જે રિપોઝિટરીમાં ક્યારેય હતા જ નહીં.
તમને શું મળે છે
કામમાં શું સમાયેલું છે.
ઓથોરાઇઝેશન ડિફોલ્ટ રૂપે
દરેક એન્ડપોઇન્ટ પર સર્વર તરફથી એ વપરાશકર્તા સામે ઓથોરાઇઝેશન જે કામ કરી રહ્યો છે, અને ઇનકાર અપવાદ નહીં પણ ડિફોલ્ટ.
હુમલો કરતા ટેસ્ટ
એવા સ્વયંસંચાલિત ટેસ્ટ જે બીજા ટેનન્ટના રેકોર્ડ માગે છે, ભૂમિકાઓ વધારે છે અને સમાપ્ત ટોકન ફરી મોકલે છે, અને દરેક વખતે ઇનકારની ખાતરી કરે છે. આ દરેક કમિટ પર ચાલે છે.
સેશન અને ટોકનનું સંચાલન
એક્સપાયરી, રિફ્રેશ અને રદ કરવાનું બરાબર ડિઝાઇન કરેલું, જેથી સમાપ્ત સેશન હંમેશાં ફરી પ્રયત્ન કરવાને બદલે સ્વચ્છ રીતે પૂરું થાય.
સિક્રેટ્સનું સંચાલન
ક્રેડેન્શિયલ રિપોઝિટરી અને કોન્ફિગ ફાઇલોની બહાર, રીડિપ્લોય વગર બદલી શકાય તેવાં, અને તેમની રોટેશન પ્રક્રિયા લેખિત.
નિર્ભરતા અને સપ્લાય ચેઇન
સ્વયંસંચાલિત નિર્ભરતા સમીક્ષા, અને એ નીતિ કે રિલીઝ ક્યારે રોકવી, સાથે લોકફાઇલ અને પુનરાવર્તનક્ષમ બિલ્ડ.
ટ્રાન્સપોર્ટ અને હેડર
TLS કોન્ફિગરેશન, HSTS, CSP અને બાકીનું બધું ઓરિજિન પર સેટ અને ચકાસેલું, એ પ્રોટોકોલ-સ્તરની સેટિંગ્સ સહિત જે ચૂપચાપ ક્લાયન્ટ તોડી નાખે છે.
સ્ટૅક
અમે તે શાનાથી બનાવીએ છીએ.
દરેક પ્રોજેક્ટ પ્રમાણે પસંદ કરેલા. અહીં કશું પણ ડિફોલ્ટ રૂપે લગાવાતું નથી, અને જે ટીમ આગળ તેને સંભાળશે તે સમસ્યા જેટલી જ મહત્ત્વની છે.
સમીક્ષા
ડેટા અને ભૂમિકાઓ પર જોખમનું મોડલ, ડિઝાઇન નક્કી થાય તે પહેલાં.
પરીક્ષણ
CI માં ઓથોરાઇઝેશન ટેસ્ટ, દરેક બિલ્ડ પર નિર્ભરતા સ્કેનિંગ, અને મહત્ત્વના માર્ગોની સમયાંતરે મેન્યુઅલ સમીક્ષા.
ઇન્ફ્રાસ્ટ્રક્ચર
ન્યૂનતમ-અધિકારવાળા સર્વિસ એકાઉન્ટ, નેટવર્ક સીમાઓ, અને એવા બેકઅપ જેની રિસ્ટોર પ્રક્રિયા ખરેખર અજમાવાઈ હોય.
દેખરેખ
ઓથેન્ટિકેશન નિષ્ફળતાઓ, ઓથોરાઇઝેશન ઇનકાર અને એરર દર પર એલર્ટ, કારણ કે એક પ્રયાસ પણ પોતે એક સંકેત છે.
પ્રતિસાદ
એ દિવસ માટે લેખિત પ્રક્રિયા જ્યારે કશું ખોટું થાય — અને તે પહેલેથી નક્કી.
સરખામણી
લોન્ચ પહેલાં સ્કેન સામે સુરક્ષાને નિર્માણનો નિર્ણય ગણવો.
સ્કેનર ચલાવવા લાયક છે અને ખરી વસ્તુઓ પકડે છે. પણ તે એ પ્રકારની ખામી નથી પકડતા જે ધંધાને ખરેખર મોંઘી પડે છે.
| પાસું | લોન્ચ પહેલાં સ્કેન | શરૂઆતથી જ અંદર |
|---|---|---|
| તૂટેલું એક્સેસ કંટ્રોલ | મોટે ભાગે છૂટી જાય છે — બીજા ટેનન્ટના રેકોર્ડની વિનંતી તદ્દન વાજબી વિનંતી જેવી જ દેખાય છે | એવા ટેસ્ટ જે જાણી જોઈને બીજા ટેનન્ટનો ડેટા માગે છે અને ઇનકારની ખાતરી કરે છે, દરેક કમિટ પર |
| જૂની થઈ ગયેલી નિર્ભરતાઓ | મળી જાય છે, અને તે ખરેખર ઉપયોગી છે | વહેલા મળે છે, અને સાથે એ નીતિ કે રિલીઝ ક્યારે રોકવી |
| ગુમ હેડર અને TLS સેટિંગ્સ | પકડાય છે | ઓરિજિન પર સેટ અને ચકાસેલું, એ પ્રોટોકોલ-સ્તરની સેટિંગ્સ સહિત જે ચૂપચાપ ક્લાયન્ટ તોડી નાખે છે |
| રિપોઝિટરીમાં પડેલા સિક્રેટ | ત્યારે મળે છે જ્યારે તે ઇતિહાસમાં નોંધાઈ ચૂક્યા હોય | ક્યારેય કમિટ જ થતા નથી, અને રીડિપ્લોય વગર બદલી શકાય છે |
| સમસ્યાઓ ક્યારે સામે આવે છે | લોન્ચના બે અઠવાડિયાં પહેલાં, જ્યારે આર્કિટેક્ચર નક્કી થઈ ચૂક્યું હોય | જ્યારે ડિઝાઇન બદલવી હજુ સસ્તી છે |
| સુધારાનો ખર્ચ | લોન્ચ પછી પરમિશન મોડલ ફરી બનાવવામાં અઠવાડિયાં અને એક માઇગ્રેશન લાગે છે | શરૂઆતમાં થોડા દિવસ, પછી લગભગ કશું નહીં |
આ કેવી રીતે ચાલે છે
પહેલી વાતચીતથી લાઇવ થવા સુધી.
આ પ્રકારના કામ માટે અંદાજિત. પાયલટ વૈકલ્પિક નથી — જ્યાં સુધી વાપરનારા એમ ન કહે કે આ ટકે છે, ત્યાં સુધી કશું સ્વિચ કરાતું નથી.
- 3-5 દિવસ
જોખમનું મોડલ
ડેટા, ભૂમિકાઓ, અને હુમલાખોર ખરેખર શું ઇચ્છશે — ડિઝાઇન નક્કી થાય તે પહેલાં.
- 2-3 અઠવાડિયાં
પાયા
દરેક એન્ડપોઇન્ટ પર સર્વર-સાઇડ ઓથોરાઇઝેશન, સેશન અને ટોકન સંચાલન, અને રિપોઝિટરીની બહાર સિક્રેટ, સાથે લેખિત રોટેશન પ્રક્રિયા.
- 1-2 અઠવાડિયાં
હુમલાખોરની જેમ કરેલા ટેસ્ટ
એવા સ્વયંસંચાલિત ટેસ્ટ જે ટેનન્ટની સીમા ઓળંગે છે, ભૂમિકાઓ વધારે છે અને સમાપ્ત ટોકન ફરી મોકલે છે, અને CI માં જોડાયેલા છે જેથી ઘટાડા પર બિલ્ડ નિષ્ફળ જાય.
- સતત ચાલુ
સતત
નિર્ભરતા નીતિ, ઓથોરાઇઝેશન ઇનકાર પર એલર્ટ, અને જરૂર પડે તે પહેલાં નક્કી કરેલી લેખિત પ્રતિસાદ પ્રક્રિયા.
લોન્ચ પછી
શું બદલાય છે.
- બિઝનેસ સોફ્ટવેરની સૌથી સામાન્ય ગંભીર ખામી આશાના ભરોસે નહીં, ટેસ્ટના ભરોસે રહે છે.
- સમાપ્ત થયેલું સેશન સ્વચ્છ રીતે પૂરું થાય છે, મરેલી વિનંતી ફરી ફરી મોકલતું રહીને કશુંક તૂટે ત્યાં સુધી નહીં.
- લીક થયેલું ક્રેડેન્શિયલ એક રોટેશન બની જાય છે, રીડિપ્લોય અને ઘટના નહીં.
- પેનિટ્રેશન ટેસ્ટ ઓછા તારણો સાથે પાછો આવે છે, કારણ કે મોંઘી ખામીઓ ડિઝાઇનમાંથી જ કાઢી નખાઈ હતી.
જાણી જોઈને ગુણાત્મક રૂપે જણાવેલું. અમે એવા ટકાવારી સુધારા પ્રકાશિત કરતા નથી જેમને અમે કોઈ નામી ક્લાયન્ટ સાથે, તેમની સંમતિથી, જોડી ન શકીએ.
પ્રશ્નો
સામાન્ય પ્રશ્નો.
શું આ પેનિટ્રેશન ટેસ્ટ છે?
ના. પેનિટ્રેશન ટેસ્ટ કોઈ સ્વતંત્ર પક્ષ દ્વારા એક સમય-વિશેષનું મૂલ્યાંકન છે, અને તે તમારે અલગથી કરાવવો જોઈએ — અમે તેનો વ્યાપ નક્કી કરવામાં મદદ કરી શકીએ. આ એ એન્જિનિયરિંગ છે જેનાથી એ ટેસ્ટ ઓછા તારણો સાથે પાછો આવે છે, અને તે ટેસ્ટ ફાઇલ થયા પછી પણ ચાલુ રહે છે.
અમારી પાસે પહેલેથી સ્કેનર છે. શું તે પૂરતું નથી?
સ્કેનર ચલાવવા લાયક છે અને ખરી વસ્તુઓ પકડે છે, પણ તે મોટે ભાગે જાણીતી નબળી નિર્ભરતાઓ અને ગુમ હેડર પકડે છે. તૂટેલું એક્સેસ કંટ્રોલ — બિઝનેસ સોફ્ટવેરની સૌથી સામાન્ય ગંભીર ખામી — વાજબી વિનંતી જેવું દેખાય છે અને તેના માટે તમારા પોતાના પરમિશન મોડલ પર લખેલા ટેસ્ટ જોઈએ.
શું તમે અમારી બનેલી એપ્લિકેશનની સમીક્ષા કરી શકો?
હા. હાલના કોડબેઝની સમીક્ષા સામાન્ય રીતે એકથી બે અઠવાડિયાં લે છે અને તર્ક સહિત અગ્રતાવાળી યાદી આપે છે, કોઈ કાચો સ્કેનર એક્સપોર્ટ નહીં. સુધારા અમે અમલમાં મૂકી શકીએ કે તમારી ટીમને સોંપી શકીએ.
શું આનાથી કામ ધીમું પડે છે?
શરૂઆતમાં થોડું, અને પછીથી ઉમેરવા કરતાં ઘણું ઓછું. ઓથોરાઇઝેશન ટેસ્ટ અને નિર્ભરતા નીતિ શરૂમાં થોડા દિવસ ઉમેરે છે; લોન્ચ પછી પરમિશન મોડલ ફરી બનાવવામાં અઠવાડિયાં અને એક માઇગ્રેશન લાગે છે.
અમારી ટીમ નાની છે. શું આ અમારા માટે વધુ પડતું નથી?
ઓથોરાઇઝેશનવાળું કામ જરૂર છે, કારણ કે તે શરૂઆતમાં સસ્તું અને પછીથી ખૂબ મોંઘું પડે છે, અને એ જ એ ખામી છે જેનાથી એક ગ્રાહકનો ડેટા બીજા સુધી પહોંચવાની સૌથી વધુ શક્યતા રહે છે. પૂરું જોખમ-મોડલિંગ અને સતત દેખરેખ ત્યાં સુધી રાહ જોઈ શકે જ્યાં સુધી દેખરેખ લાયક કશું થાય નહીં.
શું તમે અનુપાલન પ્રમાણપત્રો અપાવો છો?
અમે એ એન્જિનિયરિંગ કરીએ છીએ જેનાથી ઓડિટ સહેલું થઈ જાય — એક્સેસ કંટ્રોલ, ઓડિટ ટ્રેલ, એન્ક્રિપ્શન, ડેટા રાખવાની અવધિ, લેખિત પ્રક્રિયાઓ — પણ અમે ઓડિટર નથી અને પ્રમાણપત્રો આપતા નથી. જ્યાં કોઈ ખાસ માળખું લાગુ પડે, ત્યાં ઓડિટરને વહેલા સામેલ કરો અને અમે બરાબર એ પ્રમાણે બનાવીશું જે તેઓ ખરેખર માગે છે.