2025-10-13

【令和7年秋】情報処理安全確保支援士試験振り返り

初受験です。手応え的には去年秋の応用情報と同じくらいか？（じゃあダメじゃんｗ）

ゲタに期待したいですが、掲示板の反応みると易化してるっぽいから今回のゲタは草履くらいペラッペラでしょうな。無念。

ただ、TAC の講評では今回難易度やや高いとのことなので、どう転ぶことやら。

試験に向けて

申込みした 7 月から学習を開始し、まずテキストの「情報処理教科書情報処理安全確保支援士 2025年版」を 1 周しようとするも体系的じゃないし覚えにくいし、そもそもつまんねーな〜ってなって午前 Ⅱ の過去問演習に逃げ込みました。

その後集中力は低いながらも「情報処理教科書情報処理安全確保支援士 2025年版」を読み切り、重い腰をあげて午後の過去問も手をつけ始めました。しかし、結局午後は令和5年秋、令和5年春、令和4年秋、令和4年春の 4 つしかやらずに終わりましたｗ

というのもどれを解いても 4 〜 6 割くらいの正答率になり、応用情報のネットワークやデータベースの過去問みたいにやればやるほど初見の問題でも点取れるようになる手応えが得られず、過去問を解くモチベーションがあがらなかったんですよねえ。。

戦略的にも応用情報みたいにどれを選ぶか事前に決めることできず、範囲を絞って学習することができない辛さもありましたね。

勉強時間的には令和7年春の応用情報にかけた時間の半分以下だと思いますｗ

試験

去年秋と同じ会場だったため、電車乗り換えあり＆駅降りたあともそこそこ歩かされるという過酷な環境での受験となりました。午前 Ⅰ 免除でゆとりを持って会場に向かえたことが救いでしたね。応用情報と違ってオッサンだらけなんだろうな〜とか思ってましたが、大学生みたいな若い人たちが多くて結構アウェイ感ありました。

午前 Ⅱ

午前 Ⅱ なんて統計的にも突破率 8 割超えのガバガバの門だからマジでモーマンタイ（21/25 で 84%）

そしてやっぱり AI 関連の問題はどうしても出したいみたいっすね IPA。（モデルインバージョン攻撃たまたま知ってたからよかったけど）

午後

問題の午後。

10 分くらい各問の設問をみて問3 を除外し、問1 は XSS っぽいから選択して問2 と問4 で悩み、問4 の設問の「リスクに対応する方法は、【低減】、【？】、【？】、【？】の四つに分類される」の回答が脳みそから一切出てこなかったので問2 を選択しましたｗｗ

掲示板見ると問3, 問4 が簡単と言ってる声が多く、やっちまいましたかね〜。

問1

システムの脆弱性をついて管理者権限を奪取する元従業員さん…ｗ

これは 4 〜 6 割くらいといった出来かと…。以下自己採点用。

ここをクリックして詳細表示

設問1

できない
できる

設問2

(1) ロール管理

(2) タスク名

(3) 個人タスク

(4)

B社の管理者
締切日を過ぎた
ロールを管理者に変更する

(5) script タグだけではなく、個人タスクという文字を加えることで CSP 設定を回避した

これは完全に外しましたね

設問3

(1) スクリプトとして実行できるファイルではないことをチェックする

これも自信なし

(2) スレッド投稿

一般権限が書いたものを管理者が見れるとしたらこれじゃねーの？

(3) 投稿される文章の記号をエスケープ処理してから投稿する

設問4

ペネトレーションテストですべての機能が XSS 対策できているか検査する

SAST, DAST なんて知らんかったわ。でも DAST の内容としては似たような感じだから部分点オナシャス

問2

bitcoin の問題と見せかけて問題文でブロックチェーンの説明してるから暗号資産まわりの知識は不要なやつ。

こちらは 4 〜 7 割くらいか？知らんけど。以下自己採点用。

ここをクリックして詳細表示

設問1

イ、ウ

楕円曲線暗号とか言ってるから Elliptic Curve の EC ついてるやつ選べばいいだけじゃんとかいってやらかしました

設問2

機器が発するわずかな電波から情報を取得する

設問3

(1)

(ⅰ) と (ⅱ) の間：出庫依頼に攻撃者へBコインを移転する内容を追加する

(ⅵ) と (ⅶ) の間：攻撃者宛の出庫依頼の情報だけ削除する

(2) 使用者

これ全くわからんかったわ。勉強不足が露呈してますねえ...

(3) 通信を記録し、記録されていることを従業員に周知する

違う気もするけど不正抑止にはなるから部分点ください

設問4

(1) パスワードと移送用メディアを同じ経路で運んでいるため、盗難などで同時に紛失するリスクが高い

同時に運ぶことより、そもそも紙にパスワード書いてるのがマズイのか？

(2)

"b". ウ

"c". ア

"d". エ

"e". ウ

あ：オ

い：ク

これは自信あり。b. と e. で同じになるのに 2 箇所目も b. にせず、あえて e. にしてくるあたりニクイね〜〜

(3) 復号鍵は HSM 内にのみ存在し、署名鍵 S を複合できないため

署名鍵 S を暗号化してると決めつけてここにも署名鍵 S って書いちゃったけど大丈夫かな...

(4) 攻撃者が生成した暗号鍵

総括

去年秋の応用情報みたいに時間足りなくて空欄みたいなことにはならなかったので部分点に大いに期待したいですねえ。

受かってたらラッキー、落ちてても次はネットワーク受けるので、次次回あたりにネットワークの知識を引っ提げてリベンジしますかね。

それにしても情報処理安全確保支援士試験は楽しくなかったな〜（試験当日はなんだかんだ楽しいけど）。応用情報と違って楽しいからみんなも受けようぜ！なんて言えねえわ。

2025-04-21

【令和7年春】応用情報技術者試験振り返り

応用情報

忘れないうちに振り返っておきます。

一浪して臨んだ手応えとしては「まあ受かったんじゃね？」って感じです。

試験に向けて

もともと秋に受験してテキスト一通りと午前過去問ある程度はやってたため、春に向けてはひたすら午後の過去問演習をメインに行いました。

したがってテキストは辞書的な使い方になりました。

午前対策

ひたすら過去問。

午後対策がメインとはいえ、春に向けてだと 1 月～ 4 月で 80 問 × 26 回分やったようです。

午後対策

まず秋の反省を踏まえて戦略として

情報セキュリティ（必須）
ネットワーク
データベース
組み込みシステム
システム監査

を選択すると決めて当日に右往左往しないようにしました。経営戦略ダメゼッタイ。

ただし、情報システム開発で Git かスクラムが題材の場合のみ、組み込み or システム監査と入れ替えて選ぶつもりでいました。

また、春に向けて参考書として「応用情報技術者午後問題の重点対策」を追加で買いましたが、結果論としてはこれは買わなくても良かったかもって感じです。

情報セキュリティ

これは前回なめて痛い目にあったので、過去問平成 31 年くらいまで演習しました。

ネットワーク

秋のネットワークは易化してただけのラッキーパンチだったため、春に向けて安定して得点源にするために過去問を平成 24 年のやつくらいまで全てやりました。

最初は 3 割くらいしかとれず「あれ？ネットワーク無理じゃね？」とか思ってましたが、演習を繰り返して慣れてくると初見の問題でも 7～8 割とれる雰囲気出てきたので、これが試験勉強の醍醐味やな～って思うようになりました。

また、いずれネットワークスペシャリスト受けたいと思ってる身なので、ネットワークを避ける選択肢はありませんでした。

過去問ある程度やって思ったのは PoE 出すぎじゃね？

データベース

前回選ばなかったため、平成 31 年くらいまでやりました。

似たような問題が多い印象でこれも学習すれば得点源にできそうな雰囲気ありました。

組み込みシステム, システム監査

てめえらに対策なんてねえよ。国語力。気合。運。

試験について

0 次試験の起床もクリアして意気揚々と会場に向かい、建物見つけられず迷った末に無事（？）到着。

3 割程度は空席があるなか試験に臨みました。

お昼ご飯にはカロリーメイトと in ゼリーブドウ糖ラムネ味を持参。

午前

こちらは解答公開されてるので、自己採点結果。

はい。ジャスト 70 % でした。

当日夕方自己採点したときは 62 問正解だったから下がってて焦りましたが、まあ突破してるからヨシ！

SBOM, セキュリティクリアランス, カオスエンジニアリング 5 つの原則, ビジネスモデルキャンバスの VP など知らんやつも結構ありました。

AI 関連の問題が多くなった印象なので、今後受ける場合は対策必須かもしれません。この辺は参考書が取り入れてくれるでしょう。

午後

情報システム開発に Git, スクラムが出てこなかったため、戦略通り「情報セキュリティ（必須）」「ネットワーク」「データベース」「組み込み」「システム監査」を選択しました。

右往左往しなかったため全部解き終わって 15 分くらいあまりました。

見直しの時間で DB の解答を WITH -> FROM に修正できたので有意義でした。

情報セキュリティ

ランサムウェアは最近だとトレンドなのに問題にならないな～って思ってましたが、ついに問題になりましたね。

今回の問いで調査方法の名称をカタカナ 12 文字以内で答えよとか言ってるくせに令和2年秋の公式解答で同じような問いの解答が「ディジタルフォレンジックス（13文字）」なのは許さねえからな IPA。

俺はもともと「デジタルフォレンジクス」で覚えてたけど令和2年を解いて「ああ、公式解答がディジタルフォレンジックスだから問われたらディジタルフォレンジックスって書けるようにしなきゃ。」って脳内メモリを上書き保存したのにふざけんなよクソが。

結果、今回は「デジタルフォレンジックス（12文字）」で回答しました。ィを消すかッを消すかスを消すか悩んで 20 秒ロスしたわボケ。

ここは 7 割とれててほしい。

ネットワーク

今回一番演習して自信を持って選択しましたが、初見のやつ（SNMP）が問われて撃沈。

SNMP のやつ以外はあたってるかも知れないのでまだ解答でるまでわからんっすな。

とりあえず 6 ～ 7 割くらい期待。

データベース

まさか記述で「FROM」を書かされるとは…。（まだ正解かわからんが）

秋が鬼ムズだったのと比べると難易度は例年通りくらいですかね？

といっても結構ミスったので、なんとか 5 割とれててくれ～。

組み込みシステム

帰ってきた俺達の組み込みシステム

前回の組み込みはなかなか難しかったですが、今回は例年どおりの組み込みが帰ってきましたね。

無対策でサクサク解けるのが組み込みシステムよ。

とか言ってますが、7 割くらいしか取れてないと思いますｗ

特に「小数第2位まで求めよ。」で 0.4 と解答したのが悔やまれます。（多分 0.40 が正答なんだろうけど問題の本質じゃなくね感）

システム監査

これぞ俺達のシステム監査

無対策でサクサク解けて謝謝。

サクサク解けたけど答えがあってるかは知らん。

8 割いっててくれ。何かの間違いで 10 割でもええで。

午後解答

問題冊子をペラペラせずに自己採点できるように自分の解答をここにメモっておきます。

色付き文字は心の声。

ここをクリックして詳細表示

問１．（情報セキュリティ）

設問１．

デジタルフォレンジックス

12 文字以内でご指定のふざけた問題。「デジタルフォレンジックス」「デジタルフォレンジクス」「ディジタルフォレンジクス」等の表記ゆれは全部正解にしろよクソ IPA が。

設問２．

オ（辞書）

巷ではパスワードスプレーが正しいとか？password123456 なんて辞書攻撃の辞書にあるやろ。

ウ（RDP）

脳死で SSH 選ぶところでしたが、社内セグメントには RDP しか経由できなさそうでした。

設問３．

設定項目：ロックアウトのしきい値

理由：異なるIDに対して同一パスワードで試行できるため

自信はないけど合ってる気もするから部分点たのんます。

設問４．

(1) バックアップデータも暗号化されて調査分析が困難になる

(2) 暗号化データでログが全て上書きされるため

言わんとしてることは多分あってるやろ。部分点求む。

設問５．

ア（イミュータブル）

知らんけどイミュータブル＝上書き不可のニュアンスだけでこれを選択。

問５．（ネットワーク）

設問１．

(1) 表2項番3のMACアドレスが固定のMACアドレスと異なる

言わんとしてることは（ｒｙ

(2) 192.168.1.21

自信あり

(3) ウ（ブロードキャスト）

消去法。

(4) エ（802.1X）

認証とか言ってるから消去法でこれ。

設問２．

(1) nslookup

dig と迷ったけどどっちでも可？

(2) ウ（キャッシュDNSサーバを多重化する）

自信はないです。

設問３．

(1) ファイルサーバ

自信あり。

(2)

名称：IDS

条件：800Mビット／秒を超える大量の通信を繰り返し実行

SNMP とか知らんがな。ここは確実に外しました。

(3) ウ（ファイルサーバから社内LANへのトラフィック）

まああってるやろ。

問６．（データベース）

設問１．

郵便番号（下線なし）

主キーの下線なしで大丈夫っすかね。。

自信はないです。

設問２．

FROM

FROM 書くことなんてあるか？と思いつつ FROM しかねえよなと見直しで気づき FROM と記載。

INNER JOIN

COALESCE 使ってんだから LEFT JOIN くせえなこれ。

SUM(M.商品個数 * S.商品原価)

M.商品個数 * がいらない説もあるけどどうなん？

設問３．

AND U.キャンペーン番号 IS NOT NULL

はい。キャンペーン種別読み落としてます。無念。

ORDER BY 売上実績数 DESC

AS で命名したやつ ORDER BY でも使えるよなあ！？

設問４．

主キーの実績年月日を別表にして年と月と日をそれぞれ列名にする

自信なし。

問７．（組み込みシステム）

設問１．

ウ（走行準備→加速可能→走行中→加速可能）

これしかないやろ。

設問２．

(1) 0.1km／時未満が一定時間継続

(2) 位置情報

自信あり。

設問３．

(1)

停止中
表示

表示じゃなくてメインが正しそう...。

(2)

アクセルの操作量

やらかしたかも？？

設問４．

(1)

エ（車輪ロック解除指示）
オ（車輪ロック解除応答）
ア（貸出し応答）

多分大丈夫。

(2)

① 0.4 秒

はい。「小数第2位まで求めよ。」の罠にまんまとやられました。

② 2.54 秒

自信はないけどあっててくれ～。

問１１．（システム監査）

設問１．

(1) 手作業

(2) 入力コントロール

入力コントロールが自信ないです。

設問２．

(1) 勤務形態

(2) 部店勤務との組み合わせ

ここも自信はないけどあってる気もする。。

設問３．

(1) 人事管理

(2) 従業員の職種の誤登録

(3) X年3月末日

ここはあってるやろ？

総括

応用情報技術者試験は年に 2 回の 40,000 人が参加するお祭りじゃー！！！！！

楽しいから君も参加しないか！？

それはさておき、出来としては秋と比べたらはるかに手ごたえあるので、多分大丈夫だと思います。多分。

ダメだったらどうしようね。。一浪ですらモチベ維持がしんどかったので次は応用は受けないかも？（合否でてから要検討）

まあ、なんやかんや知識も増えた（と思ってる）し、楽しかったから落ちてても有意義だったと胸を張って言っていいでしょう。

応用情報技術者試験ありがとうございました。さらば応用情報技術者試験！！！

…

次どうすっかな～。ネットワークは春なんだよなあ。。

(2025.7.12 追記)

受かってました。やったぜ。

というわけでこの投稿は合格体験記になりました。

2025-02-09

【令和6年秋】応用情報技術者試験振り返り【今更】

応用情報

ブログ自体が久しぶりなのはさておき、合格体験記は巷に溢れかえっているので不合格者の戯言を残しておきます。

まずは試験結果

はい。7 点足りませんでした。

試験に向けて

テキストとして「応用情報技術者合格教本」を利用しました。

1 週は全ページ目を通しましたが、書いてあること全部インプットするのは無理だったので、過去問と並べながら頻出のものは身につけるイメージで使ってました。

午前対策

午前対策としてはこれまでの統計を見る限り直近 2 回からは出題されないため、令和 5 年春から平成 30 年春くらいまでを複数回解きました。

何回か解くともう計算問題でも問題文見ただけで答えまでわかってしまうようになってしまいます。（もちろん計算過程も覚えるようにはしてますが）

午後対策

午後対策としては「午後は正直運ゲーだろｗｗｗ」と思っていたため、合格教本の演習問題＋過去問 1 回分くらいしかやっておりませんでした。（これが仇となることをこのとき知る由もなかった）

戦略としても

「組み込みシステム」と「システム監査」を選択する
各問 30 分で解く

以外何も決めておりませんでした。😇

試験について

試験日は 10 月 13 日（日）でした。前日がキングオブコントだったため最後の追い込み不足感も否めなかったですね。

まあ前日ジタバタしてもしゃあねえだろと思って開き直ってキングオブコント観てましたが。。

午前問題

過去問の割合は少なかったみたいですが、初見の問題でもファインチューニングやらカルーセルみたいな個人的にはサービス問題みたいなやつがあったため無事に通過。

死の谷、魔の川、ダーウィンの海とかいうダークソウルのステージみたいなやつは外しました。（キャズムしか知らんかったぞ）

時間結構余ったので、混み始める前に便所を利用することができました。

午後問題

結果の点数から逆算するとこんな感じだったと思います。

セキュリティ 10 点
経営戦略 2 点ｗｗｗ
ネットワーク 18 点
組込みシステム開発 10 点
システム監査 13 点

セキュリティ

ここでもう少しとれていればなあといったところ。

情報セキュリティ 3 要素の「機密性」と書くべき箇所を「耐久性」と書き、さらに「耐」の字が思い出せず 5 分近く他のページ探し回ったうえ見つからず漢字も間違えていました。（まあ漢字あってても答えとしては間違いだから意味なかったんですけどね～）

だいたい半分とれてるかとれてないかくらいかと。

経営戦略

はい。今回の最大の敗因です。

試験時間残り 20 分になってから解き始めました。（残り 20 分になってから最後の問題決めてる時点で戦術的に負けてる感は否めませんが）

「(1) a」のみ正解でおそらく配点 2 点しか得られませんでした。

次回の戦略に「絶対に経営戦略を選ばない」が加えられました。

ネットワーク

今回の最大の好プレー。

過去問はどれも難しかったためネットワークは選ばないだろうなと思っていましたが、設問を見てこれはいけそうとなり選択。

結果、URL と回答すべき箇所を DNS と誤答した以外は正解でした。

組込みシステム開発

例年簡単なのに今回は難しかったですね～。

ア～カまで選択肢あるやつはマジでなんのことか分かりませんでした。

それでも半分くらいは当たっていたかと。

システム監査

あんまり覚えてないけどそこそこ当たってた気はします。

次回に向けて

最近午前の過去問解き直していますが、2 ヶ月応用情報のことを忘れて遊んでいたのに意外と覚えているもんなので、午後を重点的に対策していきます。

午後の過去問を解いてみてデータベースが結構パターン化されていて得点源にできそうなことがわかったため次回はデータベースは必ず選ぼうと思ってます。（今回難化していたので次回は例年どおりの難易度になることも期待して）

経営戦略→データベースに変えるだけで合格しそうな気もしますが、ネットワークは次は難しくなりそうなのでプログラミングか情報システム開発あたりを演習すすめてメインウェポンにしようかな。

午後を舐めていただけでちゃんとやれば次は合格するとは思ってますが奢らずに精進します。

2023-02-15

[Node.js] sinon の stub を使う

Node.js

Node.js のユニットテストが初めてで一苦労したのでまとめておきます。

目的

Node.js のユニットテストで Python でいうところの

docs.python.org

をやりたい。

例えば AWS Lambda 関数で SSM および DynamoDB から値を取得する箇所があった場合、外部サービスとの結合なので実際に AWS にアクセスするのではなくモック化してテストを行いたいのです。

前提

AWS Lambda 関数が Node.js で実装されている
AWS Lambda 関数では aws-sdk を使って SSM および DynamoDB にアクセスしている

環境

Lambda ランライム Node.js 14.x
aws-sdk 2.1215.0
mocha 10.0.0
power-assert 1.6.1
proxyquire 2.1.3
sinon 14.0.0

実装

Lambda

const aws = require('aws-sdk')
const docClient = new aws.DynamoDB.DocumentClient()

exports.handler = async (event) => {
  // SSM
  const { Parameters } = await (new aws.SSM())
    .getParameters({
      Names: ["SECRET_KEY_1", "SECRET_KEY_2"],
      WithDecryption: true,
    })
    .promise()
  // DynamoDB
  const params = {
    TableName: process.env.TABLE_NAME,
    Key: {
      id: event.arguments.id
    }
  }
  const result = await docClient.get(params).promise()

  // 処理

  return {}
}

テストコード

'use strict'
const assert = require('power-assert')
const sinon = require('sinon')
const proxyquire = require('proxyquire')

describe('Test', () => {
  let lambda
  let proxyDynamoDB
  let proxySSM
  describe('#handler()', () => {
    beforeEach(() => {
      // hide lambda log
      sinon.stub(console, 'log').returns()
      sinon.stub(console, 'error').returns()
      // stub aws
      proxyDynamoDB = class { batchGet() { } get() { } query() { } put() { } delete() { } }
      proxySSM = class { getParameters() { } }
      // inject
      lambda = proxyquire('../index.js', {
        'aws-sdk': {
          DynamoDB: { DocumentClient: proxyDynamoDB },
          SSM: proxySSM,
        }
      })
      // mock SSM getParameters
      sinon.stub(proxySSM.prototype, 'getParameters').returns({
        promise: () => Promise.resolve({
          Parameters: [
            {
              Name: 'KEY_1',
              Value: 'DUMMY_VALUE_1',
            },
            {
              Name: 'KEY_2',
              Value: 'DUMMY_VALUE_2',
            }
          ]
        })
      })
      process.env.TABLE_NAME = ''
      sinon.stub(process.env, 'TABLE_NAME').value('DUMMY_TABLE_NAME')
      const dynamoDbStub = sinon.stub(proxyDynamoDB.prototype, 'get')
      // mock DynamoDB get
      dynamoDbStub.withArgs({
        TableName: process.env.TABLE_NAME,
        Key: {
          id: 'DUMMY_ID'
        }
      }).returns({
        promise: () => Promise.resolve({
          Item: {
            name: 'DUMMY_NAME',
            email: 'DUMMY_EMAIL',
          }
        })
      })
    })
    it('テスト1', async () => {
      const event = {
        "requestContext": {
          "id": "DUMMY",
        }
      }
      await lambda.handler(event, context, () => {
      }).then(
        (data) => {
          assert.equal(data.isAuthorized, true)
        },
        (err) => {
          # FIXME: Lambda で error 発生時にテスト失敗としたい。
          # この書き方間違ってる気がするが、とりあえずテスト失敗には気がつける。
          assert.equal(0, 1, 'test failed.')
        })
    })
    afterEach(() => {
      sinon.restore()
    })
  })
})

テスト実施

$ npm i
$ npm test

補足

下書きのまま長期間熟成した記事なので色々古いと思います。

2022-10-06

[AWS SES] AWS SES でサンドボックス外に移動してから送信元メールアドレスを設定したい

AWS

結論

できません。

docs.aws.amazon.com

では先に検証済み ID を作れとの記載はないですが、通常は送信元にするメールアドレスを準備の上 SES サンドボックス解除を行うと思いますので、ほとんどの方には無意味な記事になっております。

前提

日毎の送信メール数の上限緩和をしたい。 → つまりサンドボックス解除したい。
送信元メールアドレスはまだ決まっていない。→ つまりまだ検証済み ID を登録できない。

要は「サンドボックスから脱出だけしておいて、メールアドレスを取得してから送信元メールアドレスを指定したい」という状況です。

やったこと

AWS 管理コンソールから Amazon SES > Account dashboard を開くとサンドボックス環境下である旨の警告が表示されているので、「Request production access」を選択します。
ユースケースに沿った内容を「Use case description」に記載して「Submit request」を選択します。
AWS Support > Your support cases にユースケースの記述が不足している旨の返信が即座に届きます。（最初からしっかり書いていれば届かないかもしれません。）
Amazon から届いた返信
平素は Amazon Web Servicesをご利用いただき、誠にありがとうございます。

このたびは、送信制限の申請をいただきありがとうございます。残念ながら現時点ではお客様のユースケースについて十分な情報がないため、この申請を承認することはできません。

Amazon SES の使用計画について詳しい情報をご提供いただければ、申請が承認される可能性があります。返信の際に、お客様のメール送信プロセスや手順について、可能な限り詳しい情報を記載してください。

たとえば、メールを送信する頻度、受信者リストのメンテナンス方法、バウンス、申し立て、解除申請の管理方法についてご説明ください。送信する予定のメールのサンプルをご提供いただければ、お客様が高品質のコンテンツを送信していることを確認するために役立ちます.

この情報を受け取り次第、お客様の申請を審査させていただきます。24時間以内にご連絡をいたします。必要な情報をすべてご提示いただいた場合は、24時間以内に申請を承認いたします。追加で情報が必要な場合は、申請の実装に長くかかる可能性がございますことをご了承ください。

Amazon Web Services にお問い合わせいただき、誠にありがとうございます。
AWS Support > Your support cases > Details の画面の「Reply」を選択し、ユースケースについて詳細を記述して「Submit」を選択します。
返信は即座に返ってこないため翌営業日まで待ちます。（午前中に返信していれば当日中に返信来るかもしれません。）
検証済み ID を登録する必要がある旨の返信が届きます。
Amazon から届いた返信
平素は Amazon Web Servicesをご利用いただき、誠にありがとうございます。

このたびは送信送信制限の引き上げの申請をご送信いただき、ありがとうございます。残念ながら、お客様のアジアパシフィック (東京)リージョンに検証済みIDが登録されていないため、現時点ではお客様の申請を承認することができません。

IDとはメールを送信するドメインまたは E メールアドレスのことを指します。詳細については、こちらをご覧ください(https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/verify-domains.html)。

Amazon SESのメールが送信されるメールアドレスやドメインについての情報をご提供いただければ、申請が承認される可能性があります。この情報をご提供いただける場合は、このメールにご返信ください。

返信の際、検証済みIDの登録の確認をお願いいたします。

この情報を受け取り次第、お客様の申請を審査させていただきます。24時間以内にご連絡をいたします。また、必要な情報をすべてご提示いただいた場合は、24時間以内に申請を承認いたしますが、追加で情報が必要な場合は、申請の実装に長くかかる可能性がございますことをご了承ください。

Amazon Web Services にお問い合わせいただき、誠にありがとうございます。
Amazon ご指摘の通り、検証済み ID は未登録です。

おわりに

先に Amazon SES > Configuration: Verified identities > Create identity にて検証済み ID を登録してからサンドボックス解除申請（Request production access）を行いましょう。

ちなみにまだ送信元メールアドレスは手に入ってないので、このあと検証済み ID を登録すればそれでサンドボックス解除できるかは確証無いです。（他にもハマリポイントあるかも。）

2022.10.7 追記

このあと検証済み ID を登録すればそれでサンドボックス解除できるかは確証無いです。（他にもハマリポイントあるかも。）

検証済み ID を作成し、作成した旨をサポートの「Reply」から返答したところ翌営業日にはサンドボックス解除と上限緩和ができました。

2022-09-07

[Amplify] ARM マシンでの開発で Amplify の Lambda Layer に x64 の sharp をインストールしたい

AWS

8 ヶ月ぶりの更新がこんなしょぼい内容であれですが、メモ代わりということで。

前提

Amplify および AppSync リゾルバとして Lambda を利用している。
AppSync リゾルバの Lambda で画像処理ライブラリ sharp を使いたい。

課題

AWS Lambda で sharp を利用するには arch=x64 で npm install 必要。 sharp.pixelplumbing.com
従って npm install --arch=x64 sharp でデプロイしたいが amplify push の際には npm install でインストールされるようなのでオプション指定をどうする？

※ x64 のマシンで運用する分には問題ありませんが、ARM のマシン（例：M1 Mac）の際に端末のアーキテクチャでインストールされてしまいます。

対策

※ 最善策である保証はありません。

docs.npmjs.com

script の postinstall を利用して ARM でインストール後に x64 でのインストールで上書きするようにします。

{
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "dependencies": {
    "sharp": "^0.31.0"
  },
  "scripts": {
    "postinstall": "SHARP_IGNORE_GLOBAL_LIBVIPS=1 npm install --arch=x64 --platform=linux --libc=glibc sharp"
  }
}

これによって npm install した際に x64 で sharp がインストールされます。

めでたし。めでたし。

2022-09-13 追記

初回は問題ないのですが、複数回 push していると sharp/build ディレクトリが生成されない現象がありました。

npm install でそもそも端末アーキテクチャ依存の sharp をインストールしないように preinstall で消すことで対応できました。

{
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "dependencies": {
    "sharp": "^0.31.0"
  },
  "scripts": {
    "preinstall": "npm uninstall sharp",
    "postinstall": "SHARP_IGNORE_GLOBAL_LIBVIPS=1 npm install --arch=x64 --platform=linux --libc=glibc sharp"
  }
}

2022-01-05

[DNS] BIND でローカル DNS サーバー構築

DNS

ちゃちゃっと DNS サーバーを構築をします。

AWS Route53 はゾーン設定が Web コンソールでできたので使いやすかったんだなぁと今更実感しました。

⌨️ 環境

Ubuntu 20.04

はじめに

DNS サーバーには BIND 以外にも PowerDNS や NSD などあるようですが、

en.wikipedia.org

にて

As of 2015, it is the most widely used domain name server software, and is the de facto standard on Unix-like operating systems.

と、BIND こそが Unix ライク OS の DNS サーバーでデファクトスタンダート（自称）だと仰るので、初めてですし BIND を使います。

余談ですがバージョンとしては BIND10 もあったらしいですが、プロジェクト消滅して BIND9 のリファクタリングを行う方針になったようです。（そもそも ISC のホームページの Products に BIND9 しかない。）

BIND9 には脆弱性があるという声が多いのが気になりますが、ローカル DNS ということで今回は見なかったことにします。

参考：https://ubuntu.com/search?q=Bind+vulnerability

（解消してるものも多いと思いますが、結構あります。）

1. BIND9 インストール

apt-get で BIND9 をインストールします。

$ sudo apt-get install -y bind9

2. /etc/bind/named.conf.options 設定

/etc/bind/named.conf.options を編集します。

options {
    directory "/var/cache/bind";
    dnssec-validation auto;
    //listen-on-v6 { any; };
    listen-on port 53 { localhost; };
    allow-query { any; };
    forwarders { 8.8.8.8; };
    recursion no;
}

補足

IPv6 使わない場合は listen-on-v6 をコメントアウトする
listen-on には適宜プライベートネットワークアドレスを追記する
allow-query でアクセス元を制限できる

3. ゾーンの設定

/etc/bind/named.conf を見てみると

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

とあるので、

/etc/bind/named.conf.local に zone を追記
/etc/bind/named.conf.default-zones に zone を追記
自分で追加したファイルに zone を記述して include させる

などの方法でゾーンの設定を追加できそうです。

.conf が全部そうなのかわかってませんが、やり口は Nginx の conf と同じですね。

今回は named.conf.local に追記します。

zone "mydomain.com" {
        type master;
        file "/etc/bind/db.mydomain.com";
};

ローカル DNS なので、ここでつける名前（手順の例では mydomain.com ）は取得してないドメインでも名前つけ放題です。

file "/etc/bind/db.mydomain.com" のファイルは次の手順で作成します。

4. ゾーンファイルの作成

/etc/bind/db.local をもとに編集します。

$ sudo cp /etc/bind/db.local  /etc/bind/db.mydomain.com

;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     mydomain.com. root.mydomain.com. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      www
www     IN      A       192.168.0.x

この場合は www.mydomain.com が 192.168.0.x に名前解決されます。

test.mydomain.com も追加したい場合は NS レコードと A レコードを追加します。

@       IN      NS      www
www     IN      A       192.168.0.x
@       IN      NS      test
test    IN      A       192.168.0.x

余談ですが、

NS レコード左辺の @ は何なのか
SOA レコードってそもそも何なのか

あたりがさっぱりなので、今後書くであろうゾーンファイルを掘り下げる記事でお会いしましょう。

5. BIND9 再起動

$ sudo systemctl restart bind9

6. 確認

dig コマンドで確認。

$ dig www.mydomain.com
・・・
;; ANSWER SECTION:
www.mydomain.com. 604800 IN A   192.168.0.x
・・・

名前つけ放題と先ほど言いましたが、この世に存在するドメインを名付けてパブリック DNS サーバーが先に参照されて名前解決された場合は当然ローカル DNS サーバーでの名前解決はされません。

そのため、/etc/resolv.conf でパブリック DNS サーバーの前にローカル DNS サーバーを記述してください。

resolv.conf の nameserver の順序については

linuxjm.osdn.jp

を参考にしてください。

名前解決先に Web アプリがあればそれぞれ curl で確認して同じ内容が得られます。

$ curl http://192.168.0.x
（何かしらの HTML）

$ curl http://www.mydomain.com
（何かしらの HTML）

おわりに

ゾーンファイルはテンプレートの /etc/bind/db.local をもとにしただけで使いこなせていません。

なので、今後はゾーンファイルを掘り下げていきたいですね。