ToppyMicroServices

RFC 4949 Quiz

Internet Security Glossary

🇺🇸 🇯🇵
0 / 0

References (URLs)

範囲: RFC 4949はInformationalな用語集です. 定義はdesign reviewでcategory errorを見つける助けになりますが, それだけでarchitectureやconformanceを決定するものではありません.

Q1: userが主張するidentityが正しいか確認する行為はどれ

Multiple Choice
**Explanation:** RFC 4949 Section 4はauthenticationを, entityまたはresourceが特定attribute valueを持つというclaimのverificationと定義します. loginでは通常, userが主張するidentityがそのattributeです. A: 正解. claimed identityをverifyする段階です. B: authorizationはidentityなどを基にresource accessを許可する判断です. C: identificationはuser identifierなどのclaimed valueを提示しますが, claim自体をverifyしません.

Q2: authentication済みuserがrecordをdeleteできるか決める行為はどれ

Multiple Choice
**Explanation:** RFC 4949 Section 4はauthorizationを, entityへresource accessを許可するapprovalまたはその付与processと定義します. identityと適用policyが分かった後にrequested operationを評価します. A: authenticationはattribute claimをverifyしますが, delete permissionを与えません. B: 正解. このentityへこのoperationを許すかというauthorization判断です. C: accountingはactivityの記録や計測であり, permission decisionではありません.

Q3: outsiderがdataを読めないように守る性質はどれに近い

Multiple Choice
**Explanation:** RFC 4949 Section 4で, confidentialityはunauthorized disclosureを防ぐ性質です. encryptionはそのために使えるmechanismですが, security objectiveそのものとmechanismは同一ではありません. integrityはunauthorized modificationまたはdestruction, availabilityはauthorized entityが必要なときにresourceを利用できる性質を扱います. outsiderによるreadingを防ぐという要件にはconfidentialityが対応します.

Q4: messageがtransit中に改ざんされたことを検知する性質はどれに近い

Multiple Choice
**Explanation:** RFC 4949 Section 4はdata integrityを, dataがunauthorizedな方法で変更または破壊されていない性質と定義します. integrity mechanismはtransit中のmodification検知を支えます. A: confidentialityはdisclosureを制限しますが, received dataが不変だとは示しません. B: 正解. unauthorized modificationの検知はintegrity functionです. C: availabilityは必要時のaccessやoperationを扱い, message alterationを示しません.

Q5: replay検知のためprotocol exchangeへ入れるrandomまたはnon-repeatingな値は何と呼ぶ

Multiple Choice
**Explanation:** RFC 4949 Section 4のnonceは, protocol dataへ含めるrandomまたはnon-repeatingな値で, 通常はlivenessを示しreplayを防ぐために使います. この用途ではsecrecyではなくfreshnessが中心です. A: 正解. 問いのrandomまたはnon-repeating valueです. B: credentialはsecurity判断用のevidenceやattributeですが, 必ずしもfreshではありません. C: checksumはdata changeを検知できる場合がありますが, exchangeをnon-repeatingにはしません.

Q6: validなdata transmissionを悪意をもって繰り返すattackを何と呼ぶ (英語2語)

Short Text
**Explanation:** RFC 4949 Section 4はreplay attackを, originatorまたはinterceptorによるvalid data transmissionの悪意あるまたは不正な反復と定義します. nonceなどのfreshness mechanismは以前使われたprotocol dataの拒否を支えます.

Q7: 欠けているsecurity boundaryを最も正確に指摘するterminology reviewはどれか

Multiple Choice

A2A gatewayがclient certificateをvalidateし, backendへ`X-Agent-ID`を転送します. internal network上の任意workloadも同じheaderを作成できます. backendはheaderがresource ownerを示すことだけを根拠に削除を実行します.

**Explanation:** RFC 4949 Section 4はauthentication, authorization, access controlの各glossary entryを区別します. authenticationはclaimed identityやattributeをverifyし, authorizationはpolicyに基づいてpermissionをgrantし, access controlはそのpolicyをenforceします. gatewayのcertificate checkだけでは, authenticated agentがこのbackend resourceを削除してよいかは決まりません. backendには`X-Agent-ID`とgatewayのverification resultを結ぶtrustworthyなbindingも必要です. untrusted workloadが同じheaderを作れるなら, syntaxだけではauthenticationもintegrityも得られません. protectedなgateway-to-backend trust boundaryを置く設計も, backendがevidenceを直接verifyする設計もあり得ますが, RFC 4949は一方を選びません. RFC 4949はInformationalなglossaryであり, conformance specificationではありません. ここではdesign review上のcategory errorを明確にできますが, gatewayを使う全設計を非適合とはしません.

Q8: glossaryと整合するincident用語の使い方はどれか?

Multi-Select

debug設定により再利用可能なidentity grantがshared logへ書かれます. internal accountはlogを読め, operatorが意図的にgrantをcopyして再利用しました. profileはraw grantのunauthorized log exposureをsuccessful attackとします.

**Explanation:** RFC 4949 Section 4はvulnerabilityをexploitableなflawまたはweakness, threatをharmのpotential, attackをpolicyへ反するintentional act, security compromiseをunauthorized accessへのexposureまたはpotential exposure, riskをthreat, vulnerability, harmful resultに関するexpected lossと定義します. A: 選択. logging behaviorがweaknessで, potential actorまたはeventがthreatです. B: 選択. deliberate exploitationはattackで, profileが定めたunauthorized exposureはcompromiseです. C: 選択. riskを単一のthreatやflawと区別しています. D: 非選択. actionとweaknessのcategoryが逆です. E: 非選択. transport protectionは後段のlogging sinkを制御しません.

Q9: gatewayをtrustedと呼ぶことで何が確定するか?

Multiple Choice

backendは1つのgatewayから届くidentityとauthorization resultだけを受理します. design文書はgatewayを“trusted”としますが, protected channel, isolation, review evidence, recovery planは示しません. reviewerはlabelだけでgatewayがpolicyへ違反できないと主張します.

**Explanation:** RFC 4949 Section 4はtrusted componentをpolicy enforcementへ責任を持ち, そのcorrect operationへsystem securityが依存するcomponentとして説明します. trustworthy systemはtrustedであるだけでなく, convincingなvalidationやassuranceによりtrustに値します. A: dependency labelはflawless behaviorのevidenceではありません. B: 正解. trust boundaryを示した上で, designに応じたprotectionとassuranceで支える必要があります. C: encryptionは1つのmechanismになり得ますが, この意味のtrustedを定義しません. D: Informational glossaryは用語を定義し, gateway architectureを禁止しません.

Q10: terminology-level composition reviewを通る主張はどれか?

Multi-Select

Agent Card signatureはvalidで, TLSはgatewayをauthenticateし, identity grantは期限内です. gatewayはAgent IDをbackendへ転送し, backendは固有のdelete policyを適用します. 文書はrequestが全hopでconfidential, authorized, risk-freeだと結論します.

**Explanation:** RFC 4949 Section 4はsecurity mechanismとそれが支えるservice, authenticationとauthorization, access controlとpolicy approval, trustedとtrustworthyを区別します. glossaryはreview用の正確な語彙を与えますが, composed systemの安全性を証明しません. A: 選択. valid signatureだけでresource operationはauthorizeされません. B: 非選択. 1つのchannel endpointまでのserviceはtermination後のhandlingを説明しません. C: 選択. 前提ではbackendがdelete policyのenforcement pointです. D: 選択. functional relianceがtrustを示し, trustworthinessにはassuranceが必要です. E: 非選択. check数はgapやresidual riskの分析になりません.