keita1209xtoolさんの投稿一覧

助け合いフォーラムの投稿
2026/05/31 返信
SNSのアクセスポリシーにKMSカスタマーマネージドキーの利用を許可するポリシーは不要?

SNSのアクセスポリシーやKMSのキーポリシーはリソースベースポリシーです。
リソースベースポリシーは
・そのリソース(SNSキューやKMSキー)に対して
・他のプリンシパル(Lambdaの実行ロール等)が
・何の操作を許可/拒否するか
を記述します。
Lambdaの実行ロールに付与するアイデンティティポリシーのように
「当該SNSがKMSを操作する権限を付与」することはできません。

ただ、SNSには実行ロールに相当するものがありません。
大部分のAWSサービスは実行ロールに相当するものを持ちますが、一部例外があり、仕様として暗記するしかないようです。

リソースベースポリシー(操作される側への権限記述)
アイデンティティポリシー(操作する側への権限記述)
プリンシパル(操作する主体)
を整理すると、今後のAWS学習にも役立つと思います。

2026/05/28 投稿
「telnet接続後にSMTPコマンド」という語彙について

設問に以下の記述があります。
「telnetを使用して、SMTPサーバが適切に動作しているか確認したい。telnet接続後にメールを送信するために必要なSMTPコマンドは次のうちどれか。なお、SMTPセッションは開始されているものとする。(全て選択)」

単に「telnet」と言う場合、リモートログインプロトコル名およびコマンド名を含意していると思います。
「telnet接続」という言葉は、telnetプロトコルによるリモートログインなのか、telnetコマンドがTCPコネクションを確立した状態のこと(リモートログインではない)なのか、判然としない語彙であると感じました。
この設問は「telnetコマンド(telnet servername 25)によってTCPコネクションを確立し、HELOでSMTPセッションを確立し、その後にどうするか」を問うていると思うのですが、
「telnet接続後」を「リモートログイン」だと捉えた場合は、「postfixが起動しているサーバにtelnetでリモートログインして、そこで何かしらの手段でSMTPセッションを確立し、その後にどうするか」を問うているように読み取れてしまうと感じました。

もちろんどちらであっても正解は変わらないという理解ですが、「telnet接続」という語彙が大きく意味の異なる2つの状態を指しうる=実際の現場で誤解を招きうると感じます。特にtelnetリモートログイン自体は現状、推奨されない接続形態であるため、例えば資格取得者が「telnetでSMTP動作確認します」と発言した場合、telnetポートを開放する等の危険な作業に繋がる可能性があります。

私個人としては以下のように記述するのが正確で、かつTCPセッションとアプリケーションセッション(SMTPセッション)の違いを受講者が正確に理解できるのではと思われますがいかがでしょうか。
「telnetコマンドを使用して、SMTPサーバが適切に動作しているか確認したい。SMTPセッション開始後にメールを送信するために必要なSMTPコマンドは次のうちどれか。(全て選択)」

なお、Linuc試験やLPIC試験で「telnet接続」という語彙が「telnet servername 25」を指す意味で使用されるのであれば、その旨も記載していただけると助かります。

2026/05/24 投稿
smtpd_sasl_pathは「認証情報を受け渡すパスを指定」ではないのか

PostfixでSMTP認証を行う際、PostfixとSASLプラグインが認証情報を受け渡す方法を指定する項目はどれか。
正答:smtpd_sasl_path
解説:SMTP認証にはSASL(Simple Authentication and Security Layer)という安全な認証を提供する仕組みを利用します。SASLはCyrus-SASLプラグインまたはDovecot-SASLプラグインが利用できます。

Dovecot-SASLが提供するソケットファイルを指定する
smtpd_sasl_path = private/auth

解説を読むと、smtpd_sasl_pathは、情報を渡す相手(パス)を指定しているように見えました。
「パスを指定する」は「受け渡す相手を指定する」であり、「受け渡す方法を指定」とは違うように思われ
設問に違和感があります。
「受け渡す方法」は「SASLの実装種別」と捉えるほうが自然に思え、その場合は
smtpd_sasl_typeが正答になってしまうと感じました。

2026/05/02 投稿
requireは認証対象ではなく認可対象ではないか

Apacheでダイジェスト認証を使用したい。認証対象とするユーザまたはグループを指定するhttpd.confのディレクティブは次のうちどれか。
正解:Require

Requireで指定するのは、
認証対象=ID+パスワード(+レルム)の一致確認
ではなく
認可対象=アクセス権を与えるかどうか
ではないでしょうか。

たとえばauthuserfileに指定したパスワードファイルにID/PWが存在するが、
requireに指定されていないユーザーでアクセスした場合、
認証は通る
認可は与えられない
という状況になると思います。
これを「認証が通らなかった」「認証されなかった」と表現するのは誤りで、
「認証はされたが認可が与えられなかった(権限がなかった)」と表現されるべきではないでしょうか。

requireは認証の要不要を問わず、認可対象を表現しているはずであり、
「requireで認証対象を指定する」
という設問および解説は誤りだと思います。

合格体験記の投稿
投稿がありません