PostmanとOWASP ZAPによるAPIセキュリティテスト
APIテスト自動化ツールとしてOWASP ZAPを利用し、脆弱性診断の方法からレポート生成までの手順を記載します。
今回の方法では、PostmanのリクエストをOWASP Zapに送ることで脆弱性診断を実施しています。
Postmanを利用することができるので、既存のコレクションの使い回しをすることができます。
前提条件
PostmanとOWASP Zapがインストールされていること
インストールされていない方は下記リンクからインストールしてください。
手順概要
OWASP Zapの設定をする
OWASP Zapの"Settings"→"LocalServers / Proxy"を開きます。
ポートを指定します。上記のスクリーンショットの場合は8081に指定しています。
Postmanの設定をする
OWASP Zapの"Settings"→"Proxy"を開きます。
“Use custom proxy configuration” を有効にし、下記を設定します。
Proxy Server : 127.0.0.1 Port : 8081 (OWASP Zapで指定したポート)
PostmanでAPIをOWASP Zapに登録する
Postmanで、目的のAPIコレクションからAPIリクエストを送信します。
Postmanから送信したAPIリクエストは、OWASP Zapの サイトに登録されます。
OWASP Zapで脆弱性の確認(動的スキャン)をする
メインディレクトリを右クリックし、"攻撃 "→"動的スキャン "を選択します。
ポリシーはデフォルトのものを使用します。
スキャンが完了すると、「アラート」セクションに脆弱性が表示されます。
結果のレポートを生成する
OWASP Zapの"レポート"→"Generate Report"でレポートを生成します。
生成されたレポートは以下のようにHTMLファイルとして表示できるようになります。
補足
脆弱診断の終了後はPostmanプロキシ設定を以前の/デフォルト設定に戻しておきましょう。
参考リンク
自立の本質を考える〜脳性麻痺の小児科医の言葉から〜
先日こんな言葉と出会いました。
「自立は依存先を増やすこと。希望は、絶望を分かち合うこと。」
脳性麻痺の障害を持ちながらも小児科医として活躍される熊谷晋一郎さんの言葉です。
わたしがこの言葉にどうやって出会ったかと言うと、土門蘭さんの「死ぬまで生きる日記」というエッセイを年始に読んでいたところ、その文章の中に先の言葉が記述されていました。
自立と依存っていうのが相反する言葉なので、パッと見どういう意味なんだろうって興味を持ちました。
そこで、インターネットを使ってこの言葉を調べてみると、あるネット記事が見つかりました。
その記事を読んでみると以下のようなことが書いてありました。
健常者はさまざまなものに依存できていて、障害者は限られたものにしか依存できていない。依存先を増やして、一つひとつへの依存度を浅くすると、何にも依存してないかのように錯覚できます。“健常者である”というのはまさにそういうことなのです。世の中のほとんどのものが健常者向けにデザインされていて、その便利さに依存していることを忘れているわけです。
実は膨大なものに依存しているのに、「私は何にも依存していない」と感じられる状態こそが、“自立”といわれる状態なのだろうと思います。
これを読んで、2児の父でもあるわたしは真っ先に「子どもとの関係性もそうだな」と思いました。
例えば、子どもに「お買い物行ってきて」って言うふうにお願いするとします。
けれど、子どもたちはどうやってお買い物したらいいかわからないので、「パパママ手伝って」って言うふうになると思います。
これは世間一般的に見たら自立していないから1人でお買い物できないって言うふうに捉えられるかもしれません。
じゃあ大人は1人で買い物できるから、何も依存してないといえるかっていうと、そうではないかなって思います。
例えば、買い物場所のお店を調べるためにスマホで検索したり、お店まで移動するために電車に乗ったり、またお店でも商品の場所を店員さんに聞いてみたりと。
いろんなもの・人に依存してるって思いませんか?
そう考えると、自立っていうのは熊谷さんが仰るように、何かに依存しないって言うことではなくて、依存先を増やして上手に使いこなすことで、あたかも何にも依存していないように見えるっていう状態のことなのかなぁと思います。
そしてこれって、仕事をする上でも一緒じゃないかなと思っていて
例えば新卒育成とかを担当している時、やっぱり「新卒に早く自立して欲しいな」って言うふうに思いますね。
でもそれって新卒が、誰にも頼らずに1人で仕事できるようにって言う意味ではなく、むしろ逆で、会社内で頼れる人。つまりはネットワークっていうのどんどん広げてもらって依存先を増やしてもらうことじゃないかなと思います。
だから、新卒育成の時(新卒に限らずですが)、重要なのは「誰かに頼らずとも仕事が出来るようになって」みたいな感覚で接するのではなくて、
むしろ誰かに助けてもらう方法だったり、何かの案件で困ったときは 何を使ってどのように調べればいいのか、つまりはどのように依存したらいいのかっていうのを教えてあげることが自立につながるんではないかなと思います。
結局は人と人との関係なので、自分1人で解決できるっていう事は少なくて、誰かと協力して応援しあえるネットワークっていうのどんどん広げていくっていうことが本当の意味での自立した大人。自立したビジネスマン。なんじゃないかなぁって考えます。
エンジニアリングマネージャーの仕事とそのエッセンス
株式会社アトラクタの吉羽氏がForkwell主催のイベントにて「エンジニアリングマネージャーのしごと」を題目としてお話しされていました。
youtubeにその動画が公開されていたので、要点をまとめ、自分の考察も追記し記事にしておくことにします。
なお、動画は下記。
1. 基本的な役割
私自身は、マネージャーの仕事とは、突き詰めると「チームメンバーを幸せにすること」だと思っています。
その上で、エンジニアリングマネージャーの仕事は以下4つの側面があります。
- ピープルマネジメント:メンバーのモチベーションや成長をサポートする。
- テクノロジーマネジメント:技術的な課題や変更を管理・サポートする。
- プロジェクトマネジメント:プロジェクトの進行やリソースを適切に管理する。
- プロダクトマネジメント:製品の方向性や戦略を形成・管理する。
2. キャパシティ管理
エンジニアリングマネージャーは、稼働率100%の消防車のような状態を避ける必要があります。
多くの予期しない仕事が発生するため、常にキャパシティの余裕を持つことが重要です。
チームを適切にサポートし、自分自身の考える時間を確保するためにも、バランスの取れた働き方が必要です。
3. 自己管理の重要性
情報は四方八方から飛び込んでくるため、エンジニアリングマネージャーは自分自身の情報整理能力を高める必要があります。
記憶に頼る情報はなるべく少なくするために、カレンダーやTODOリスト、情報記録ツールの活用は積極的に行いましょう。
整理整頓された状態でなければ、チームを効果的にサポートすることは難しいですし、自分のキャパシティを確保することもできないでしょう。
4. アウトプット
エンジニアリングマネージャーはチーム全体のアウトプットが自身のアウトプットとなるため、自分のタスクをこなすよりも、チームの成果向上のための権限移譲(メンバーにタスクを任せること)やメンタリングに時間を割くことが大切です。
エンジニアリングマネージャーは、常にチームの成果を最優先に考える必要があります。
5. 4つの仕事の分類
マネジメントの仕事としては、以下の4分類がある。
- 情報収集:1on1、雑談、チャット、MTG、etc
- 意思決定:採用決定、面接候補者決定、PRレビュー...
- ナッジング:自分の観点を提供して決定に影響を与える。
- ロールモデル:残業しないこと, 勉強会での発表など、実例を示すことでチームの指針となる。
6. 移譲の重要性とその方法
マネージャーがすべてのタスクを自分でこなすのは非効率的です。
そのため、移譲が不可欠となります。
ただし、移譲する際には段階を踏むことや、説明責任を保持することが重要です。
移譲でやるべきこと、やってはいけないこととしては下記があります。
- やるべきこと
- 移譲すること
- 相手にとってチャレンジになるくらい移譲すること
- タスクの重要性に応じて、適切なコントロールを持ち続けること
- やってはいけないこと
- 丸投げ
- 他の人のやり方が自分と同じであると期待すること
- 渡したタスクを取り返すこと
まとめ
エンジニアリングマネージャーの役割は多岐にわたり、チームのサポートを最優先に考える必要があります。
「マネージャーはメンバーのために存在するものである」ことを常に意識しましょう。
適切なキャパシティ管理、情報整理、アウトプットの最大化、そして効果的な移譲が、マネージャーとしての成功を導く鍵となります。
あなたのJavaScriptコードをシンプルにする:let、if、constの理解と活用
「letが多くなるとifが多くなる。そうするとコードが複雑になっていく傾向がある」
先日、JavaScriptを書いていたら、先輩からこんなレビューをもらいました。
最初はいまいちピンときませんでしたが、自分なりに、その意味を考え、まとめてみました。
ということで、JavaScriptの基本的な構文であるlet、if、そしてconstの使用について、わたし自身の学びと考えを共有します。
それでは、まずはなぜletとifが多くなるのか、そしてそれがどのようにコードの複雑さに繋がるのかから話を始めます。
なぜletとifが多くなるのか?
まず、なぜ多くの初心者がletとifを多用するのでしょうか?
それは、状況に応じて変数の値を変えるためや、特定の条件下で何かを行うためによく使われます。
例えば次のようなコードを考えてみます。
let temperature = 22; let weather = ""; if (temperature > 30) { weather = "暑い"; } else if (temperature > 20) { weather = "適温"; } else { weather = "寒い"; } console.log(weather);
ここで、letとifはそれぞれ2つずつ使用されています。
これはあくまで一例ですが、このようなパターンは非常に一般的だと思います。
constの利用
一方、constは定数を宣言するときに使います。
これは、一度値が設定されると変更できない変数です。
しかし、constを適切に利用することで、letとifの数を減らし、コードをシンプルにすることができます。
同じ機能を持つ先ほどのコードをconstを使って書き換えてみます。
const temperature = 22; const weather = temperature > 30 ? "暑い" : temperature > 20 ? "適温" : "寒い"; console.log(weather);
ここではconstと三項演算子(条件演算子)を使っています。
三項演算子(条件演算子)はif-else文のより短いバージョンのようなもので
条件 ? 真の場合の値 : 偽の場合の値
という形で書くことができます。
letとifを使うよりもかなりシンプルになったように思います。
constのメリット
constで宣言された変数は、一度設定されるとその後は変更することができません。
この性質によってどんなメリットがあるのでしょうか?
予測可能性: 一度設定された値が変わらないため、プログラムがどのように動作するかを理解しやすくなります。これは特に大規模なプロジェクトや複数人での開発で有利です。
バグの防止: 変数の値が意図せず変更されることによるバグを防ぐことができます。
可読性: 一度設定した値が再び変更されないことで、他の開発者がコードを読んで理解するのが容易になります。
constを使った配列の操作
さて、次に配列に関する例を考えてみます。
以下のコードでは、配列内の特定の条件を満たす要素を新しい配列に追加します。
let numbers = [1, 2, 3, 4, 5]; let evenNumbers = []; for(let i = 0; i < numbers.length; i++) { if(numbers[i] % 2 === 0) { evenNumbers.push(numbers[i]); } } console.log(evenNumbers);
上記コードについては実はletをconstにしても動作はしますが、冗長な感じが否めません。
このコードをconstと配列のメソッドfilterを使って書き換えてみます。
const numbers = [1, 2, 3, 4, 5]; const evenNumbers = numbers.filter(number => number % 2 === 0); console.log(evenNumbers);
ここではfilterメソッドを使用しています。
これは配列の各要素に対してテスト関数を実行し、その結果がtrueとなる要素からなる新しい配列を生成します。
このように書くことで、letとifの使用がなくなり、さらに簡潔になりました。
まとめ
プログラミング初心者がJavaScriptを書く際、状況に応じて変数の値を変更したり、特定の条件で何かを実行したりするために、letとifを多用することがよくあります。
しかし、constと条件演算子や配列のメソッドを適切に使用することで、コードをよりシンプルで簡潔にでき、保守も容易になります。
また、constの使用はコードの予測可能性を高め、意図せずに変数の値が変更されるバグを防ぎ、可読性を高めることがわかりました。
今後もJavaScriptの学習を続ける上で、let、if、constなどの基本的な構文の理解と使い分けを意識していこうと思います。