AI తో నిర్మించిన యాప్‌ల కోసం భద్రతా చెక్‌లిస్ట్: ప్రారంభానికి ముందు ఏం తనిఖీ చేయాలి

మీరు AI తో నిర్మించిన యాప్‌ను నిజమైన వ్యక్తులు వాడే ముందు ఏడు విషయాలు తనిఖీ చేయండి: ప్రతి పేజీ మరియు API వినియోగదారు ఎవరో, వారు ఏం చేయవచ్చో తనిఖీ చేస్తుంది; రహస్య కీలు సర్వర్‌లోనే ఉంటాయి, బ్రౌజర్ లేదా చాట్‌లో ఎప్పుడూ కాదు; ప్రతి ఇన్‌పుట్ సర్వర్‌లో ధృవీకరించబడుతుంది; ప్రతి వినియోగదారు కేవలం తన స్వంత రికార్డులను మాత్రమే చేరుకోగలడు; లాగిన్ మరియు ఖర్చు ఎక్కువైన ఎండ్‌పాయింట్‌లపై రేట్ లిమిట్‌లు ఉంటాయి; డిపెండెన్సీలు తాజాగా ఉంటాయి; మరియు ఏదైనా తప్పు జరిగితే మీ డేటాను తిరిగి తీసుకురాగలరు. క్రింది చెక్‌లిస్ట్ వీటిని కోడ్ చదవకుండానే మీరు చేయగల నిర్దిష్ట పరీక్షలుగా మారుస్తుంది.

AI యాప్ బిల్డర్లు ఫీచర్లను పనిచేసేలా చేయడంలో మంచివారు. వారు స్వయంచాలకంగా జాగ్రత్తగా ఉండరు, ఎందుకంటే “జాగ్రత్త” అనేది చాలా అరుదుగా ప్రాంప్ట్‌లో ఉంటుంది. క్రింది సమస్యల్లో చాలావరకు ఎవరూ అడగని విషయాల నుంచే వస్తాయి, కాబట్టి పరిష్కారం సాధారణంగా అడగడమే.

ఈ చెక్‌లిస్ట్‌ను ఎలా ఉపయోగించాలి

క్రమంగా పని చేయండి, మరియు ప్రతి అంశానికి రెండు పనులు చేయండి: అది నిర్వహించబడిందని నిర్ధారించుకోవడానికి AI ని అడగండి, మరియు మీరే పరీక్షించండి. AI అనుమతి తనిఖీని రాయగలదు; అది పనిచేస్తుందో లేదో ఒక పరీక్ష మాత్రమే చెబుతుంది. అంశాలు ఇలా గుర్తించబడ్డాయి:

• Must — ఎవరైనా ఇతరులు యాప్‌ను వాడే ముందు దీన్ని చేయండి.
• Should — మీకు నిజమైన వినియోగదారులు లేదా నిజమైన డేటా రాకముందు దీన్ని చేయండి.
• Later — యాప్ పెరిగేకొద్దీ చేయదగినది.

మీకు ఒక గంట మాత్రమే ఉంటే, ప్రతి Must చేయండి.

1. ప్రామాణీకరణ: ఇది ఎవరు?

ప్రామాణీకరణ (Authentication) అంటే ఒకరు ఎవరో నిర్ధారించడం — సాధారణంగా లాగిన్. ప్రాథమిక అంశాల కోసం ప్రామాణీకరణ అంటే ఏమిటి చూడండి, మరియు ఎంపికల కోసం మీ యాప్‌కు లాగిన్ ఎలా జోడించాలి చూడండి.

• Must: వ్యక్తిగత డేటా చూపే ప్రతి పేజీకి లాగిన్ అవసరం. పరీక్ష: లాగ్ అవుట్ అవ్వండి, ఆపై ఒక ప్రైవేట్ పేజీ URL ను నేరుగా బ్రౌజర్‌లో అతికించండి.
• Must: ఆ పేజీల వెనుక ఉన్న ప్రతి API ఎండ్‌పాయింట్‌కూ లాగిన్ అవసరం — కేవలం పేజీకి కాదు. పరీక్ష: లాగ్ అవుట్ అవ్వండి, బ్రౌజర్ నెట్‌వర్క్ ట్యాబ్ తెరవండి, మీరు లాగిన్ లో ఉన్నప్పుడు యాప్ చేసిన అభ్యర్థనను మళ్లీ ప్రయత్నించండి.
• Must: పాస్‌వర్డ్‌లు నెమ్మదైన పాస్‌వర్డ్-హ్యాషింగ్ అల్గారిథమ్‌తో హ్యాష్ చేసి నిల్వ చేయబడతాయి, ఎప్పుడూ సాధారణ టెక్స్ట్‌లో కాదు. OWASP పాస్‌వర్డ్ నిల్వ మార్గదర్శకం Argon2id ను మొదటిగా సిఫార్సు చేస్తుంది, scrypt, bcrypt లేదా PBKDF2 ప్రత్యామ్నాయాలుగా ఉంటాయి. AI ని అడగండి: “పాస్‌వర్డ్‌లు ఎలా నిల్వ చేయబడతాయి?”
• Should: పాస్‌వర్డ్ రీసెట్ లింక్‌లు గడువు ముగుస్తాయి మరియు ఒక్కసారి మాత్రమే పనిచేస్తాయి.
• Should: సెషన్ కుకీలు Secure, HttpOnly మరియు SameSite గా గుర్తించబడతాయి, మరియు లాగ్ అవుట్ చేస్తే సర్వర్‌లో సెషన్ ముగుస్తుంది.
• Later: టూ-ఫ్యాక్టర్ ప్రామాణీకరణను అందించండి, లేదా దాన్ని కలిగి ఉన్న ప్రొవైడర్ ద్వారా సైన్-ఇన్ చేయండి.

వినియోగదారు డేటా తిరిగి ఇచ్చే ప్రతి API రూట్ మరియు పేజీని తనిఖీ చేయండి. ప్రతిదీ లాగిన్ కాని వినియోగదారుల అభ్యర్థనలను పేజీ కోడ్‌లో మాత్రమే కాకుండా, సర్వర్‌లో తిరస్కరించాలి. మీరు తనిఖీ చేసిన రూట్‌ల జాబితా ఇవ్వండి.

2. అధికారం: వారు ఏం చేయడానికి అనుమతించబడ్డారు?

అధికారం (Authorization) అనేది లాగిన్ తర్వాత దశ: ఈ నిర్దిష్ట వినియోగదారు ఏం చూడగలరు మరియు ఏం మార్చగలరు అని నిర్ణయించడం. AI తో నిర్మించిన యాప్‌లకు తీవ్రమైన లోపాలు తరచుగా ఇక్కడే ఉంటాయి, ఎందుకంటే యాప్ సరిగ్గా కనిపిస్తుంది — ప్రతి వినియోగదారి డ్యాష్‌బోర్డ్ కేవలం వారి స్వంత డేటాను మాత్రమే చూపుతుంది — కానీ నేరుగా అడిగితే సర్వర్ ఎవరి డేటానైనా ఇచ్చేస్తుంది.

• Must: ప్రతి చదవడం, అప్‌డేట్ మరియు డిలీట్ ప్రస్తుత వినియోగదారికి (లేదా వారి టీమ్‌కు) ఆ రికార్డు చెందుతుందో సర్వర్‌లో తనిఖీ చేస్తుంది.
• Must: పరీక్షించండి: రెండు ఖాతాలు సృష్టించండి, A మరియు B. A గా, A యొక్క ఒక రికార్డు తెరిచి, URL లేదా నెట్‌వర్క్ అభ్యర్థనలో దాని ID ను గమనించండి. B గా లాగిన్ అయి అదే ID ను అడగండి. B కు ఒక ఎర్రర్ రావాలి, A డేటా కాదు.
• Must: అడ్మిన్ పేజీలు మరియు అడ్మిన్ API ఎండ్‌పాయింట్‌లు సర్వర్‌లో వినియోగదారి పాత్ర (role) ను తనిఖీ చేస్తాయి. అడ్మిన్ లింక్ దాచడం రక్షణ కాదు.
• Must: అభ్యర్థనను మార్చడం ద్వారా వినియోగదారులు తమ స్వంత role, ధర, బ్యాలెన్స్ లేదా owner ఫీల్డ్‌లను మార్చలేరు. పరీక్ష: నెట్‌వర్క్ ట్యాబ్‌లో ప్రొఫైల్ అప్‌డేట్ ఏం పంపుతుందో చూడండి. అందులో role లేదా isAdmin వంటి ఫీల్డ్‌లు ఉంటే, క్లయింట్ నుంచి వాటిని విస్మరించమని AI ని అడగండి.
• Should: URLల్లోని IDలు ఊహించడం కష్టంగా ఉండాలి (1, 2, 3 కు బదులుగా యాదృచ్ఛిక IDలు). ఇది అనుమతి తనిఖీలకు ప్రత్యామ్నాయం కాదు, కానీ ఒకటి లేనప్పుడు నష్టాన్ని తగ్గిస్తుంది.

ఒక రికార్డును చదివే లేదా మార్చే ప్రతి ఎండ్‌పాయింట్ కోసం, లాగిన్ అయిన వినియోగదారి దాని యజమాని అని లేదా దాన్ని యాక్సెస్ చేయడానికి అనుమతించబడ్డారని సర్వర్‌లో తనిఖీ చేయండి. కాకపోతే 404 ఇవ్వండి. తర్వాత రెండు ఖాతాలతో దీన్ని ఎలా పరీక్షిస్తారో చూపించండి.

3. డేటాబేస్‌లో రో-స్థాయి యాక్సెస్

“రో-స్థాయి యాక్సెస్” అంటే ఒక టేబుల్‌లోని ప్రతి వరుస (ఒక బుకింగ్, ఒక ఇన్‌వాయిస్) కేవలం దానికి చెందిన వినియోగదారులకే కనిపిస్తుంది. దీన్ని అమలు చేయడానికి రెండు సాధారణ మార్గాలు ఉన్నాయి:

రెండూ బాగా చేయవచ్చు. ముఖ్యమైనవి:

• Must: బ్రౌజర్ నేరుగా డేటాబేస్‌తో మాట్లాడితే (కొన్ని హోస్ట్ చేసిన డేటాబేస్ ఉత్పత్తులు అలా అనుమతిస్తాయి), ప్రతి టేబుల్‌కు రో-స్థాయి నియమాలు ఆన్ చేయబడాలి. లేకపోతే, పబ్లిక్ కీ ఉన్న ఎవరైనా మొత్తం టేబుల్‌ను చదవగలరు.
• Must: క్వెరీలు బ్రౌజర్ పంపిన ID ద్వారా కాకుండా ప్రస్తుత వినియోగదారి లేదా టీమ్ ద్వారా ఫిల్టర్ చేయబడతాయి.
• Should: షేర్ చేసిన డేటాకు (టీమ్ ప్రాజెక్ట్‌లు) ఎవరు టీమ్‌లో ఉన్నారో స్పష్టమైన నియమం ఉంటుంది, అది ఒకే చోట అమలు చేయబడుతుంది.

4. సీక్రెట్లు మరియు API కీలు

API కీ అనేది ఒక సేవకు పాస్‌వర్డ్. Stripe, ఇమెయిల్ మరియు AI ప్రొవైడర్లు అందరూ వీటిని ఉపయోగిస్తారు. నేపథ్యం కోసం, ఎన్విరాన్‌మెంట్ వేరియబుల్స్ మరియు సీక్రెట్లు అంటే ఏమిటి చూడండి.

• Must: కీలు ప్రాజెక్ట్ యొక్క ఎన్విరాన్‌మెంట్ వేరియబుల్స్ లేదా సీక్రెట్లలో ఉంటాయి, ఎప్పుడూ కోడ్‌లో రాయబడవు.
• Must: డబ్బు ఖర్చు చేయగల లేదా ప్రైవేట్ డేటా చదవగల కీలు సర్వర్‌లో మాత్రమే ఉపయోగించబడతాయి. పరీక్ష: మీ లైవ్ సైట్ తెరిచి, పేజీ సోర్స్ మరియు డెవ్‌టూల్స్‌లోని JavaScript ఫైళ్లను చూడండి, మీ కీ ప్రారంభాన్ని (ఉదా. sk_) వెతకండి. అది కనిపించకూడదు.
• Must: కీలను ఎప్పుడూ చాట్, పబ్లిక్ రిపోజిటరీ లేదా స్క్రీన్‌షాట్‌లో అతికించలేదు. అలా జరిగితే, ప్రొవైడర్ వద్ద కీని రొటేట్ చేయండి (కొత్తది సృష్టించండి, పాతది తొలగించండి).
• Should: ప్రొవైడర్ అందిస్తే పరిమిత లేదా స్కోప్ చేసిన కీలను ఉపయోగించండి. ఉదాహరణకు Stripe, మీ ఇంటిగ్రేషన్‌కు అవసరమైన అనుమతులు మాత్రమే ఉన్న పరిమిత కీలను సిఫార్సు చేస్తుంది.
• Should: టెస్ట్ మరియు లైవ్ కీలు వేరుగా ఉంటాయి, మీరు సిద్ధంగా ఉన్నప్పుడే లైవ్ యాప్ లైవ్ కీలను ఉపయోగిస్తుంది.

కొన్ని కీలు పబ్లిక్‌గా ఉండేలా రూపొందించబడతాయి — Stripe యొక్క పబ్లిషబుల్ కీ (pk_…) లేదా మీ డొమైన్‌కు పరిమితం చేసిన మ్యాప్స్ కీ. నియమం అధికారాన్ని ఇచ్చే కీల గురించి, కీలా కనిపించే ప్రతి స్ట్రింగ్ గురించి కాదు.

5. ఇన్‌పుట్ ధృవీకరణ

వినియోగదారు పంపే ప్రతిదీ — ఫారమ్ ఫీల్డ్‌లు, ఫైల్ అప్‌లోడ్‌లు, URL పారామీటర్‌లు — మీ ఫారమ్ అనుమతించేది మాత్రమే కాకుండా ఏదైనా కావచ్చు.

• Must: ధృవీకరణ సర్వర్‌లో జరుగుతుంది, కేవలం బ్రౌజర్‌లో కాదు. బ్రౌజర్ తనిఖీలు సౌలభ్యం కోసమే; ఎవరైనా వాటిని దాటవేయవచ్చు.
• Must: డేటాబేస్ క్వెరీలు పారామీటర్‌లను ఉపయోగిస్తాయి, వినియోగదారు ఇన్‌పుట్ నుంచి అతికించిన టెక్స్ట్ కాదు (ఇది SQL ఇంజెక్షన్‌ను నివారిస్తుంది). AI ని ధృవీకరించమని అడగండి.
• Must: వినియోగదారులు నమోదు చేసే టెక్స్ట్ HTML గా కాకుండా టెక్స్ట్‌గా ప్రదర్శించబడుతుంది. పరీక్ష: మీ పేరుగా <b>hello</b> నమోదు చేయండి. మీకు బోల్డ్ టెక్స్ట్ కాకుండా ట్యాగ్‌లు కనిపించాలి.
• Should: ఫైల్ అప్‌లోడ్‌లు రకం మరియు పరిమాణం తనిఖీ చేస్తాయి, మరియు అప్‌లోడ్ చేసిన ఫైళ్లు మీ యాప్ ప్రధాన డొమైన్ నుంచి రన్ అయ్యే పేజీలుగా సర్వ్ కావు.
• Should: వినియోగదారులకు చూపే ఎర్రర్‌లు సాదాగా ఉంటాయి (“ఏదో తప్పు జరిగింది”); వివరణాత్మక ఎర్రర్‌లు సర్వర్ లాగ్‌లకు మాత్రమే వెళ్తాయి.
• Should: Stripe వంటి సేవల నుంచి వచ్చే వెబ్‌హుక్‌లు చర్య తీసుకునే ముందు ప్రొవైడర్ సంతకాన్ని ధృవీకరిస్తాయి. వెబ్‌హుక్ అంటే ఏమిటి చూడండి.

ప్రతి ఫారమ్ మరియు API ఎండ్‌పాయింట్‌కు సర్వర్-వైపు ధృవీకరణ జోడించండి: అవసరమైన ఫీల్డ్‌లు, పొడవులు, ఫార్మాట్‌లు మరియు అనుమతించబడిన విలువలు. మిగతావన్నీ స్పష్టమైన సందేశంతో తిరస్కరించండి. అంతర్గత ఎర్రర్ వివరాలను వినియోగదారులకు చూపకండి.

6. రేట్ లిమిట్‌లు మరియు దుర్వినియోగం

రేట్ లిమిట్ అంటే ఒక వ్యవధిలో ఎవరైనా ఎన్ని అభ్యర్థనలు చేయగలరో పరిమితి. అవి లేకపోతే, ఎవరైనా రోజంతా పాస్‌వర్డ్‌లు ఊహించగలరు, మీ సైన్అప్ ఫారమ్‌ను నింపేయగలరు, లేదా చెల్లింపు API పై మీ బిల్లును పెంచగలరు.

• Must: లాగిన్, సైన్అప్ మరియు పాస్‌వర్డ్ రీసెట్‌లు IP చిరునామా మరియు ఖాతా వారీగా రేట్-లిమిట్ చేయబడతాయి.
• Must: ప్రతి కాల్‌కు మీకు డబ్బు ఖర్చయ్యేవి — AI మోడల్ అభ్యర్థనలు, SMS, ఇమెయిల్ — ప్రతి వినియోగదారికి పరిమితి కలిగి ఉంటాయి మరియు లాగిన్ అవసరం.
• Should: పబ్లిక్ ఫారమ్‌లు (సంప్రదింపు, వెయిట్‌లిస్ట్) స్పామ్ రక్షణ కలిగి ఉంటాయి: రేట్ లిమిట్, దాచిన హనీపాట్ ఫీల్డ్ లేదా CAPTCHA.
• Should: మీ చెల్లింపు ప్రొవైడర్ల వద్ద ఖర్చు పరిమితులు లేదా హెచ్చరికలు సెట్ చేయండి, తద్వారా ఒక బగ్ లేదా దాడి అపరిమిత బిల్లును సృష్టించలేదు.

7. డిపెండెన్సీలు

యాప్‌లు ఓపెన్-సోర్స్ ప్యాకేజీల నుంచి నిర్మించబడతాయి, మరియు ప్యాకేజీలకు కొన్నిసార్లు తెలిసిన లోపాలు ఉంటాయి.

• Should: తెలిసిన లోపాల కోసం తనిఖీ చేయమని AI ని అడగండి (JavaScript ప్రాజెక్ట్‌ల కోసం npm audit లేదా మీ ప్యాకేజీ మేనేజర్‌కు సమానమైనది) మరియు ప్రభావితమైన వాటిని అప్‌డేట్ చేయండి.
• Should: యాప్ ఇక ఉపయోగించని ప్యాకేజీలను తొలగించండి.
• Should: చాలా తక్కువ మంది వాడే ప్యాకేజీలు లేదా ప్రసిద్ధ వాటి అక్షర దోషాల్లా కనిపించే పేర్లపై జాగ్రత్తగా ఉండండి.
• Later: ప్రతి ఒకటి రెండు నెలలకు మళ్లీ తనిఖీ చేయండి, లేదా మీ కోడ్ GitHub లో ఉంటే స్వయంచాలక హెచ్చరికలు ఆన్ చేయండి.

8. బ్యాకప్‌లు మరియు పునరుద్ధరణ

భద్రతలో మీరు చేసే తప్పుల నుంచి కోలుకోగలగడం కూడా భాగం — మీవి, AI వి, లేదా దాడి చేసేవారివి.

• Must: మీ డేటా ఎక్కడ ఉందో, అది బ్యాకప్ చేయబడుతుందో లేదో తెలుసుకోండి. ఊహించకండి; మీ హోస్ట్ డాక్యుమెంటేషన్‌లో తనిఖీ చేయండి.
• Should: ముఖ్యమైన డేటాకు మీ స్వంత ఆవర్తన ఎగుమతిని ఉంచండి (ఉదాహరణకు CSV ఎగుమతి ఫీచర్ లేదా డేటాబేస్ డంప్), వేరే చోట నిల్వ చేసి.
• Should: మీ కోడ్‌ను వెర్షన్ కంట్రోల్‌లో ఉంచండి, తద్వారా ఏ వెర్షన్‌నైనా పునరుద్ధరించవచ్చు.
• Should: విధ్వంసక చర్యలు (ఖాతా తొలగింపు, ప్రాజెక్ట్ తొలగింపు) నిర్ధారణ అడుగుతాయి, మరియు కొంతకాలం రద్దు చేయగల “సాఫ్ట్ డిలీట్” ను పరిగణించండి.
• Later: ఒకసారి పునరుద్ధరణను నిజంగా పరీక్షించండి. ఎప్పుడూ పునరుద్ధరించని బ్యాకప్ ఒక ఆశ మాత్రమే, ప్రణాళిక కాదు.

9. ప్రారంభానికి ముందు

• Must: లైవ్ సైట్ ప్రతిచోటా HTTPS ఉపయోగిస్తుంది.
• Must: డెవలప్‌మెంట్ నుంచి వచ్చిన నమూనా డేటా, టెస్ట్ ఖాతాలు మరియు డీబగ్ పేజీలు తొలగించబడ్డాయి.
• Should: గోప్యతా విధానం మీరు ఏ డేటా సేకరిస్తారో మరియు ఎందుకో చెబుతుంది — వ్యక్తిగత డేటా సేకరిస్తే అనేక చోట్ల ఇది అవసరం. మీ వద్ద లేని ధృవపత్రాలను (SOC 2, HIPAA) క్లెయిమ్ చేయకండి.
• Should: భద్రతా సమస్యల గురించి మిమ్మల్ని సంప్రదించే మార్గం ఉంది, మరియు ప్రతి కీని త్వరగా రొటేట్ చేయడం మీకు తెలుసు.

భద్రతకు మించి విస్తృత ప్రీ-లాంచ్ తనిఖీ కోసం, AI ప్రోటోటైప్‌ను ప్రొడక్షన్‌కు ఎలా తీసుకెళ్లాలి చూడండి.

ప్రొఫెషనల్ సమీక్ష ఎప్పుడు అవసరం

చెక్‌లిస్ట్ సాధారణ తప్పులను పట్టుకుంటుంది; అది నిపుణుడిని భర్తీ చేయదు. మీరు హోస్ట్ చేసిన చెక్అవుట్ ద్వారా కాకుండా కార్డు నంబర్లను నేరుగా ప్రాసెస్ చేస్తే, ఆరోగ్యం, ఆర్థిక లేదా పిల్లల డేటాను నిల్వ చేస్తే, భద్రతా ప్రశ్నావళులు అడిగే కంపెనీలకు అమ్మితే, లేదా లీక్ వల్ల తీవ్ర నష్టం జరిగితే, సమీక్ష కోసం చెల్లించడాన్ని పరిగణించండి. మీ కోడ్ ఎగుమతి చేయగలిగితే అలాంటి సమీక్ష చాలా సులభం అవుతుంది.

Mythex తో నిర్మించేటప్పుడు భద్రత

Mythex లో భద్రతా స్కాన్ ప్యానెల్ లేదు, కాబట్టి పై చెక్‌లిస్ట్ అనుసరించాల్సిన ప్రక్రియ. సహాయపడే కొన్ని విషయాలు:

• ప్రాజెక్ట్ సీక్రెట్లు. కీలను ప్రాజెక్ట్ సెట్టింగ్‌లు → Secrets కింద, లేదా ఏజెంట్ చాట్‌లో చూపే secrets కార్డ్ ద్వారా నిల్వ చేయండి, తద్వారా అవి మీ కోడ్ మరియు సందేశాల్లో ఉండవు. లైవ్ యాప్ కోసం సీక్రెట్ మార్చిన తర్వాత మళ్లీ ప్రచురించండి.
• Plan మరియు Ask మోడ్‌లు. ఎడిట్ చేయకుండా అనుమతులు సమీక్షించమని ఏజెంట్‌ను అడగండి: “Ask మోడ్‌లో, ప్రతి API రూట్ మరియు అది ఏ అనుమతి తనిఖీ చేస్తుందో జాబితా చేయండి.”
• /test ఏజెంట్ మీ ప్రివ్యూలో ఒక వినియోగదారిగా క్లిక్ చేస్తుంది — సెక్షన్ 2 లోని రెండు-ఖాతాల పరీక్షకు ఉపయోగకరం.
• చెక్‌పాయింట్‌లు విరిగిన మార్పును వెనక్కి తీసుకోవడానికి అనుమతిస్తాయి.

డాక్స్‌లో మీరు నిర్మించే యాప్‌ల భద్రత మరియు ఎన్విరాన్‌మెంట్ వేరియబుల్స్ మరియు సీక్రెట్లు చూడండి. తర్వాత వినియోగదారు ఖాతాలు జోడించాలనుకుంటే, మీ యాప్‌కు లాగిన్ ఎలా జోడించాలి చదవండి.

ప్రశ్నలు